TRANSPORT LAYER AND MODEL FOR AN ADVANCED METERING INFRASTRUCTURE (AMI) NETWORK

Abstract

Mesh networks, network devices, and computer program products for implementing a transport layer. The transport layer is operable to provide connection oriented transport layer services to at least one of an application layer, a presentation layer, and a session layer. The transport layer header flags essentially consist of: SYN, ACK, PSH, and RST.

Description

CROSS REFERENCES TO RELATED APPLICATIONS

The present application claims the priority benefit of pending U.S. Provisional Patent Application No. 60/989,967, titled “Efficient and Compact Transport Layer and Model for an Advanced Metering Infrastructure (AMI) Network,” filed Nov. 25, 2007 (the “Provisional Application”). The complete disclosure of the Provisional Application is hereby incorporated herein by reference in its entirety.

This application claims the benefit of priority to the following United States provisional patent applications which are incorporated herein by reference in their entirety:

• • Ser. No. 60/989,957 entitled “Point-to-Point Communication within a Mesh Network”, filed Nov. 25, 2007 (TR0004-PRO);
  • Ser. No. 60/989,958 entitled “Creating And Managing A Mesh Network Including Network Association,” filed Nov. 25, 2007 (TR0005-PRO);
  • Ser. No. 60/989,964 entitled “Route Optimization Within A Mesh Network,” filed Nov. 25, 2007 (TR0007-PRO);
  • Ser. No. 60/989,950 entitled “Application Layer Device Agnostic Collector Utilizing ANSI C12.22,” filed Nov. 25, 2007 (TR0009-PRO);
  • Ser. No. 60/989,953 entitled “System And Method For Real Time Event Report Generation Between Nodes And Head End Server In A Meter Reading Network Including From Smart And Dumb Meters,” filed Nov. 25, 2007 (TR0010-PRO);
  • Ser. No. 60/989,975 entitled “System and Method for Network (Mesh) Layer And Application Layer Architecture And Processes,” filed Nov. 25, 2007 (TR0014-PRO);
  • Ser. No. 60/989,959 entitled “Tree Routing Within a Mesh Network,” filed Nov. 25, 2007 (TR0017-PRO);
  • Ser. No. 60/989,961 entitled “Source Routing Within a Mesh Network,” filed Nov. 25, 2007 (TR0019-PRO);
  • Ser. No. 60/989,962 entitled “Creating and Managing a Mesh Network,” filed Nov. 25, 2007 (TR0020-PRO);
  • Ser. No. 60/989,951 entitled “Network Node And Collector Architecture For Communicating Data And Method Of Communications,” filed Nov. 25, 2007 (TR0021-PRO);
  • Ser. No. 60/989,955 entitled “System And Method For Recovering From Head End Data Loss And Data Collector Failure In An Automated Meter Reading Infrastructure,” filed Nov. 25, 2007 (TR0022-PRO);
  • Ser. No. 60/989,952 entitled “System And Method For Assigning Checkpoints To A Plurality Of Network Nodes In Communication With A Device Agnostic Data Collector,” filed Nov. 25, 2007 (TR0023-PRO);
  • Ser. No. 60/989,954 entitled “System And Method For Synchronizing Data In An Automated Meter Reading Infrastructure,” filed Nov. 25, 2007 (TR0024-PRO);
  • Ser. No. 60/992,312 entitled “Mesh Network Broadcast,” filed Dec. 4, 2007 (TR0027-PRO);
  • Ser. No. 60/992,313 entitled “Multi Tree Mesh Networks”, filed Dec. 4, 2007 (TR0028-PRO);
  • Ser. No. 60/992,315 entitled “Mesh Routing Within a Mesh Network,” filed Dec. 4, 2007 (TR0029-PRO);
  • Ser. No. 61/025,279 entitled “Point-to-Point Communication within a Mesh Network”, filed Jan. 31, 2008 (TR0030-PRO), and which are incorporated by reference.
  • Ser. No. 61/025,270 entitled “Application Layer Device Agnostic Collector Utilizing Standardized Utility Metering Protocol Such As ANSI C12.22,” filed Jan. 31, 2008 (TR0031-PRO);
  • Ser. No. 61/025,276 entitled “System And Method For Real-Time Event Report Generation Between Nodes And Head End Server In A Meter Reading Network Including Form Smart And Dumb Meters,” filed Jan. 31, 2008 (TR0032-PRO);
  • Ser. No. 61/025,282 entitled “Method And System for Creating And Managing Association And Balancing Of A Mesh Device In A Mesh Network,” filed Jan. 31, 2008 (TR0035-PRO);
  • Ser. No. 61/025,271 entitled “Method And System for Creating And Managing Association And Balancing Of A Mesh Device In A Mesh Network,” filed Jan. 31, 2008 (TR0037-PRO);
  • Ser. No. 61/025,287 entitled “System And Method For Operating Mesh Devices In Multi-Tree Overlapping Mesh Networks”, filed Jan. 31, 2008 (TR0038-PRO);
  • Ser. No. 61/025,278 entitled “System And Method For Recovering From Head End Data Loss And Data Collector Failure In An Automated Meter Reading Infrastructure,” filed Jan. 31, 2008 (TR0039-PRO);
  • Ser. No. 61/025,273 entitled “System And Method For Assigning Checkpoints to A Plurality Of Network Nodes In Communication With A Device-Agnostic Data Collector,” filed Jan. 31, 2008 (TR0040-PRO);
  • Ser. No. 61/025,277 entitled “System And Method For Synchronizing Data In An Automated Meter Reading Infrastructure,” filed Jan. 31, 2008 (TR0041-PRO); and
  • Ser. No. 61/094,116 entitled “Message Formats and Processes for Communication Across a Mesh Network,” filed Sep. 4, 2008 (TR0049-PRO).

This application hereby references and incorporates by reference each of the following United States patent applications filed contemporaneously herewith:

• • Ser. No. ______ entitled “Point-to-Point Communication within a Mesh Network”, filed Nov. 21, 2008 (TR0004-US);
  • Ser. No. ______ entitled “Efficient And Compact Transport Layer And Model For An Advanced Metering Infrastructure (AMI) Network,” filed Nov. 21, 2008 (TR0003-US);
  • Ser. No. ______ entitled “COLLECTOR DEVICE AND SYSTEM UTILIZING STANDARDIZED UTILITY METERING PROTOCOL,” filed Nov. 21, 2008 (TR0009-US);
  • Ser. No. ______ entitled “METHOD AND SYSTEM FOR CREATING AND MANAGING ASSOCIATION AND BALANCING OF A MESH DEVICE IN A MESH NETWORK,” filed Nov. 21, 2008 (TR0020-US); and
  • Ser. No. ______ entitled “System And Method For Operating Mesh Devices In Multi-Tree Overlapping Mesh Networks”, filed Nov. 21, 2008 (TR0038-US).

BACKGROUND OF THE INVENTION

1. Field of the Invention

This application is directed to systems, methods, and computer program products of a transport layer and transport model. The transport layer and transport model are particularly well adapted to the Automated Meter Infrastructure (AMI) and Automated Meter Reading (AMR) environments.

2. Description of the Related Art

A mesh network is a wireless network configured to route data between nodes within the network. It allows for continuous connections and reconfigurations around broken or blocked paths by retransmitting messages from node to node until a destination is reached. Mesh networks differ from other networks in that the component parts can all connect to each other via multiple hops. Thus, mesh networks are self-healing: the network remains operational when a node or a connection fails.

AMI, AMR, or Advanced Metering Management (AMM) technologies include systems that measure, collect and analyze utility usage, from advanced devices such as electricity meters, gas meters, and water meters, through a network on request or a pre-defined schedule. This infrastructure includes hardware, software, communications, customer-associated systems and meter data management software. The infrastructure collects and distributes information to customers, suppliers, utility companies and service providers. This enables these businesses to either participate in, or provide, demand response solutions, products and services. Customers may alter energy usage patterns from normal consumption patterns in response to demand pricing. This improves system load and reliability.

Mesh networks may include at least one mesh gate and at least one mesh device, such as a meter. The mesh gate may communicate with the meters over a mesh network. The mesh gate may also communicate with a server over a wide area network. The mesh gate may form a mesh network with nearby meters and interface between the meters and the server.

The Open Systems Interconnection Basic Reference Model (OSI Reference Model or OSI Model) provides a layered, abstract description for communications and computer network protocol design, developed as part of the Open Systems Interconnection (OSI) initiative. It is also called the OSI seven layer model. The layers are conventionally, from top to bottom, Application, Presentation, Session, Transport, Network, Data Link, and Physical. A layer is a collection of related functions that provides services to the layer above it and receives service from the layer below it. For example, a layer that provides error-free communications across a network provides the path needed by applications above it, while it calls the next lower layer to send and receive packets that make up the contents of the path.

The typical or conventional Transport layer (layer 4) under the OSI model provides transparent transfer of data between end users, providing reliable data transfer services to the upper layers. The transport layer may typically control the reliability of a given link through flow control, segmentation and/or de-segmentation, and error control.

Although it was not developed under the OSI Reference Model and does not strictly conform to the OSI definition of the Transport Service, the best known example of a layer 4 protocol is the Transmission Control Protocol (TCP).

Of the actual OSI protocols, not merely protocols developed under the model, there have heretofore generally considered to be five classes of transport protocols, ranging from class 0 (which is also known as TP0 and provides the least error recovery) to class 4 (which is also known as TP4 and is designed for less reliable networks, similar to the Internet). Class 4 is closest to TCP, although TCP contains functions, such as the graceful close, which OSI assigns to the Session Layer.

The conventional or typical Network layer (Layer 3) under the OSI model provides the functional and procedural means of transferring variable length data sequences from a source to a destination via one or more networks while maintaining the quality of service requested by the Transport layer. The Network layer performs network routing functions, and might also perform fragmentation and reassembly, and report delivery errors. One known example of a layer 3 protocol is the Internet Protocol (IP).

BRIEF SUMMARY OF THE INVENTION

The technology includes networks, network devices, and computer program products for implementing a transport layer. Each embodiment has a transport layer module operable to provide connection oriented transport layer services to an application layer, a presentation layer, and a session layer. The transport layer header flags essentially consist of: SYN, ACK, PSH, and RST. In some embodiments, a connection is terminated only by a computer program product operating on a network device sending or receiving a message with the RST flag set, or by a timeout. In some embodiments data can be transferred in a message from a receiving node containing the first set ACK flag of a connection. In some embodiments sequence numbers are assigned only at the packet level. In some embodiments, the packet level is the minimum level of data segmentation. In some embodiments, a transport layer implemented by the transport layer module directly interfaces with a data link layer without the presence of a separate network layer.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:

FIG. 1 illustrates an embodiment of the TIP protocol shown in the context of related AMI protocols.

FIG. 2 illustrates an AMI packet including a TIP header of the present technology.

FIG. 3 is a state diagram of the present technology illustrating how connections can be established and closed.

FIG. 4 illustrates TIP aspects of a simple communication between nodes of the present technology.

FIG. 5 illustrates communication between two nodes where a first node sends a message indicating the beginning of a segmented request (e.g., no PSH flag set), but a second node does not support segmented requests.

FIG. 6 illustrates communication between two nodes for a multiple unsegmented request/unsegmented response pairs.

FIG. 7 illustrates communication between two nodes where a first node sends an unsegmented request and second node responds with a segmented response.

FIG. 8 illustrates communication between two nodes for a segmented request prompting an unsegmented response.

FIG. 9 illustrates communication between two nodes for a segmented request and a segmented response.

FIG. 10 illustrates communication between two nodes for an unsegmented request and segmented response when piggybacking is not possible.

FIG. 11 illustrates a coordinator of the present technology serving to move data formatted in a UDP message from an IP node in an IP network to a TIP node of a mesh network.

FIG. 12 illustrates a coordinator of the present technology facilitating communication between an IP node of an IP network sending a TCP-formatted message to a TIP node of a mesh network.

DETAILED DESCRIPTION OF THE INVENTION

Detailed embodiments of the present invention are disclosed herein. However, it is to be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The figures are not necessarily to scale, and some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the present invention. Further, individual characteristics of the technology can be omitted from any given embodiment or combined in various ways to produce patentable embodiments of the technology.

For purpose of brevity of description, embodiments of the inventive transport layer and transport model, including implementing structures, methods and procedures, and computer program product and data structure features are referred to by the acronym TIP.

In combination with technologies that implement the functionality of other layers of a protocol stack, e.g., the technology described in pending U.S. Provisional Patent Application No. 60/989,957 as enabling transfers of short packets (e.g., 80 bytes of payload) between nodes within a mesh network (hereby incorporated herein by reference in its entirety), the present transport layer technology enables reliable transmission of large messages. The technology provides end-to-end acknowledgement of messages, rejection of duplicate packets, multi-packet messaging, and port multiplexing within a network node.

Referring to FIG. 1, the TIP protocol 100 is shown in the context of related AMI protocols. A protocol stack used in intra-mesh operations, e.g., between two permanently installed meters in neighbouring homes, is shown in the first column 110. A protocol stack for a conventional wide area network (WAN), e.g., TCP/IP-enabled devices in an AMI application, is shown in the third column 120. A simplified protocol stack used for direct communication during installation, maintenance, and walk-by of an AMI node is shown in the middle column 130.

TIP implements functions similar to IP and TCP in a single layer. With regard to IP functionality, TIP uses a smaller transmission unit, e.g., a single IEEE 802.15.4 packet. Version control, priority, flow label, payload length, next header, and hop limit as used in IP are not transported. Source address and destination address are only sometimes transported, as will be described in more detail below. Option headers are not used.

Further in contrast to TCP, TIP employs packet-level sequence numbers instead of byte-level sequence numbers—in protocol stacks employing TIP it is not allowed for an intermediate node to re-fragment a packet, hence the TCP byte-level sequence number is not required.

In contrast to TCP, TIP presents a single packet window. This approach is possible, in part, because some target networks employing TIP in the protocol stack, e.g., AMI networks, present homogeneous, half duplex, low latency characteristics. TIP is less complex than TCP to implement, requires less resources, and removes the need to include the window size in the header.

Under TIP, unlike under TCP, termination of a connection is through one message, i.e., RST, rather than through three, i.e., FIN, ACK, and then ACK. Further, offset and checksum are not transported; fixed timeouts are used; and the URG flag and urgent pointer are not supported. An early open feature, representing the ability to piggyback payload data during a three-way connection handshake, is provided.

In comparison to TCP/IPv6 packets, which introduce an overhead of at least 64 bytes on all packets, TIP introduces an overhead of 21 bytes for communication between an AMI node and an IPv6 node on the first packet of a communication, and only a 4-byte overhead on subsequent packets. For inter-mesh communication not involving a TCP/IP node in the route, both the first and all subsequent packets are burdened with only a 4-byte overhead.

Referring to FIG. 2, an AMI packet 200 including a TIP header 210 of the present technology is shown. The packet 200 includes: an IEEE 802.15.8 Media Access Control (MAC) header 220; a mesh network header 230; a header for layers above the transport layer in conventional protocols, shown as an Application Header 240; and a packet payload 250. As indicated above, for direct communication during installation, maintenance, and walk-by of an AMI node the mesh network header 230 is not used.

In some embodiments, the TIP header 210 includes an eight-bit flag field 212. The flag field 212 uses bits 5-7 (three bits) to indicate extension type. For example, in bits 5, 6, and 7, binary values 000 and 001 can be reserved to avoid conflicts with extended mesh network service; binary values 010, 011, and 111 also can be reserved; binary value 100 indicates intra-TIP communication; binary value 101 can indicate IPv4 communication with TIP; and binary value 110 can indicate IPv6 communication with TIP. Bit 4 is a flag for acknowledgment (ACK); bit 3 is a flag for the push message (PSH); bit 2 is a flag for the reset message (RST); bit 1 is a flag for synchronization (SYN). Finally bit 0 is reserved.

The TIP headers include an eight-bit sequence number 214 pre-incremented for each transmitted packet, excluding acknowledgement messages and retries. The TIP header also contains the value of the last packet sequence number received by the sender of the current packet.

TIP allows port addressing within a node. In some embodiments, ports 0-2 are inbound ports used for regular reporting, high priority reporting, and on-demand ANSI C12.22 respectively; ports 3 and 4 are reserved; ports 5-14 are outbound ports with 5-9 used for ASNI C12.22 relaying to WAN to LAN NATing and ports 10-14 used for internal processes such as mass upgrade and mass configuration of network nodes. In some embodiments, port 0 is reserved; port 1 is an outbound port for ASNI C12.22 reporting; port 2 is an inbound port for on-demand ANSI C12.22; ports 3-14 are reserved; and port 15 is an inbound RFD proxy port.

The TIP header further contains an extension field 218 defined by the extension type bits, e.g., bits 5-7 of the flag field 212, e.g., as one of intra-TIP, IPv4/TIP, and IPv6/TIP. When extension type is set to intra-TIP, the extension field 218 is formatted as an eight-bit field where bits 5-7 indicates a source port number; while bits 0-3 indicate a destination port number. When the extension type is set to IPv4/TIP, then the extension field is a seven-byte (56-bit) field using 32 bits for the IP address of the node on IPv4 network, 16 bits for the port number at the IPv4 address, and 8 bits for the port number of the TIP network address (though in some embodiments, less than 8 bits may be used). When the extension type is set to IPv6/TIP, then the extension field uses 128 bits for the IPv6 address, 16 bits for the port address at the IPv6 address, and the last 4 bits of the final byte for the port number of the TIP network address.

Implementations of the technology turn the relatively unreliable and very basic services provided by a data link layer into a more powerful technology for AMI communications through the use of a connection-oriented approach that provides same-order delivery, improved data reliability through retransmission of packets, flow control, streaming, and port addressing.

Regarding connection establishment, a communication is started between a source and a target (potential destination) by the exchange of packets with the SYN flag set. The initial “packet sequence number” is set to an arbitrary value from a range of valid sequence numbers to mitigate the risk of false duplicate packet detection. The “packet sequence number” returned is also set to a separate arbitrary value from the range. The “last received sequence number” returned from the destination is set to the “packet sequence number” received last by that node. The first packet is accepted by the target unless duplicated. The first packet is considered duplicated if received before the timeout, e.g., eight (8) seconds, with the same “packet sequence number” and CRC. Only packets received with the SYN flag set and a matching “last received sequence number” are processed as a connection establishment. Packets with the SYN flag set are processed the same way as a packet transporting data, they are retried until acknowledged.

Messages larger than packet size are retransmitted using multiple consecutive packets. The maximum segment size depends on the transport mode used.

The “packet sequence number” is incremented independently by each side (source, target/destination) for each packet sent, which includes a SYN packet or a payload packet, excluding retries. The “packet sequence number” is not incremented for packets sent as an acknowledgment (ACK). In fact, the “package sequence number” of an ACK is not processed and is present primarily to keep the header fixed in size. A packet received with a “packet sequence number” equal to the “packet sequence number” of the last packet received plus one has its payload transferred to the next layer up in the TIP protocol.

The ACK flag is not set in the first packet sent during a connection establishment and the “last received sequence number” is set to zero and not processed by the target node. Subsequent packets have the ACK flag set and the “last received sequence number” set to the “packet sequence number” of the last valid packet received. The piggyback of ACK and data is done only if the data is available in time, e.g., within 500 msec, If not, then an empty packet is sent with the ACK flag set. The type of acknowledgment-only packets are not retries. Packets received with the SYN, PSH, and RST flags set are not acknowledged and are processed if not duplicated. An unacknowledged packet is considered duplicated if received before timeout, e.g., eight (8) seconds, with the same “packet sequence number” and CRC.

Referring to FIG. 3, a state diagram of the present technology is shown to illustrate how connections can be established and closed. Beginning at the Closed 310 state for the convenience of description, a node may open in one of two ways: passively 312 or actively 314. The node may passively open itself to communication by Listening 340 on the network for a SYN sent to its port. A node, e.g., a meter reporting an unexpected increase in usage, enters a new state, SYN Sent 320, after sending a message with the SYN flag set.

In the passive mode, a node Listens 340 to receive a SYN 342 and responds by sending a message with SYN and an ACK flags set 344, putting the node in the SYN Received 330 state.

In the SYN Sent 320 state, the node can return to the Closed 310 state by receiving a message with the RST flag set or via timeout 322. The node can enter the Connection Established 350 state upon receipt of a message with SYN and ACK flags set 324 after sending a message in response with the ACK flag set 326; or the node can open simultaneous communication 328 with another node by receiving a message with the SYN flag set and sending a message with the ACK flag set.

In the SYN Received 330 state, a receipt of a message with the ACK flag set 332 in response to a message sent with SYN and ACK flags set 344 moves the node to a Connection Established 350 state. If no message is received before a timeout occurs, or a message with the RST flag set is received while the node is in the SYN Received 330 state, then the node returns to the Listen 340 state. In other embodiments, the node returns to the Closed 310 state under those circumstances.

FIG. 4 illustrates TIP aspects of a simple communication between nodes 400. Specifically, a single unsegmented request and unsegmented reply communication is shown. Node 410 sends 412 a first packet with SYN and PSH flags set, having a packet sequence number set to a arbitrary number within the valid packet sequence number range, e.g., 46, last received sequence set to 0, and a data payload (e.g., of a Protocol Specification for Electronic Metering (PSEM) request to Node 420). Node 420 responds 422 with a message having SYN, ACK, and PSH flags set, with its own arbitrary packet sequence number 22, and with last received packet sequence number equal to that of Node 410's last sent message 412; and with the response to the PSEM request as the data payload of the message. In some embodiments, node 410 closes the connection by sending 430 a message having an empty data field and the ACK and RST flags set.

FIG. 5 illustrates communication 500 between two nodes where the Node 510 sends 510 a message indicating the beginning of a segmented request (e.g., no PSH flag set), but Node 520 does not support segmented requests. Node 520 indicates such by sending 522 a packet with the RST flag set, last received packet sequence number with the correct value, and an empty data field. Node 510's message 520 indicated that a segmented request was starting by not setting the PSH flag.

FIG. 6 illustrates communication 600 between two nodes 610, 620 for a multiple unsegmented request/unsegmented response pairs. Each message from Node 610 bearing an unsegmented request, e.g., 612, 614, 616, has the PSH flag set. The first message 612 from Node 610 over the connection has the SYN flag set, while subsequent unsegmented messages 614, 616, 618 have the ACK flag set. The connection is terminated by Node 610 using a message 618 with the RST flag set.

FIG. 7 illustrates communication 700 between two nodes 710, 720 where node 710 sends an unsegmented request and node 720 responds with a segmented response. The unsegmented PSEM request is sent in message 712 with SYN and PSH (indicating that the message contains unsegmented data, e.g., data not divided across more than one massage) set. Node 720 responds with a message 722 having SYN and ACK flags set and data if the first segment of the PSEM response. Notice that the PSH flag is not set in messages 722 or 724 from node 720; this indicates to node 710 that more segments are to follow. Also notice that after sending 712 the unsegmented request, node 710 repeats the packet sequence number of its original request, but keeps track new packet numbers received from node 720.

FIG. 8 illustrates communication 800 between two nodes 810, 820 for a segmented request prompting an unsegmented response. The initial message 812 from node 810 has the SYN flag set, is numbered arbitrarily, and contains the first segment of a PSEM request. Node 820 responds with a message 822 having SYN and ACK flags set, its own arbitrary packet sequence number, and a confirmation of the packet sequence number first sent in the message 812 from node 810. The data field of message 822 is empty or ignored. Node 820 then sends messages 814, 816 with incremented sequence numbers and containing the remaining portions of the PSEM request. The message 816 containing the last portion of the PSEM request also has its PSH flag set, signalling the end of the PSEM request. Notice that Node 820 does not increment its packet sequence number when acknowledging subsequent segments of the PSEM request. Node 820 then responds 826 to the completed PSEM request with a packet having a sequence number incremented from the initial Node 820 number for this connection.

FIG. 9 illustrates communication 900 between two nodes 910, 920 for a segmented request and a segmented response. Node 910 sends a message 912 having the SYN flag set and having the first segment of the request in the data field. Node 920 responds with a message 922 having SYN and ACK flags set and provides its own packet sequence number. Node 910 then sends a message 914 with incremented sequence number and the remaining portion of the request—indicating that this is the final portion of the request by setting the PSH flag. Node 920 then begins responding to the request by sending a message 924 with the first segment of the response, the ACK flag set (but not the PSH flag set), and its own incremented sequence number. Node 910 then acknowledges receiving the first segment of the response with a message 916 having an empty data section and with only its ACK flag set. Node 920 completes the response by sending a message 926 having both ACK and PSH flags set. Node 910 then terminates the connection through a message 918 having ACK and RST flags set.

The examples of FIGS. 4-9 use piggybacking, e.g., the responding node 920 includes response data in the first acknowledging message (e.g., one having an ACK flag set, e.g., 924) after receiving the completed request (e.g., 914) from the sending node, e.g., 920. FIG. 10 illustrates communication between two nodes 1010, 1020 for an unsegmented request and segmented response when piggybacking is not possible, e.g., when response data is not available in a timely fashion, e.g., before the requesting node is expected to time out. In response to a message 1012 from node 1010 initiating communication (e.g., SYN flag set and packet sequence number assigned) for an unsegmented (e.g., PSH flag set indicating that this first segment is the last segment) data field, node 1020 replies with a message 1022 having SYN and ACK flags set, packets sequence number assigned, and last received packet sequence number acknowledged, but having an empty data field (possibly because data was not ready in time enough to respond timely to the request). Node 1010 responds 1014 to message 1022 with an un-incremented acknowledgment of receiving a message with the serial number 36. When data is ready, node 1020 begins an otherwise-routine transfer of each segment using messages 1026 and 1028. Node 1010 performs routine inter-segment acknowledgment 1016 and connection termination 1018.

Network devices of the present technology include mesh network end devices, mesh routers, and mesh coordinators. FIG. 11 illustrates a coordinator 1110 of the present technology serving to move data formatted in a UDP message 1122 from an IP node 1120 in an IP network 1124 to a TIP node 1130 of a mesh network 1131. If the UDP message 1122 has data longer than accommodated in a single TIP message data field, then the coordinator 1110 segments the data and handles establishing, maintaining, and terminating the connection with the TIP node 1130. Consistent with earlier description, the coordinator established communication through use of the SYN flag 1132, and responds to acknowledgement 1134 from the TIP node 1130 with successive data packets 1136 after receiving each acknowledgment 1138 until the last portion of the data is passed and a message including a set RST flag is sent 1139.

FIG. 12 illustrates a coordinator 1210 of the present technology facilitating communication between an IP node 1220 of an IP network 1224 sending a TCP-formatted message to a TIP node 1230 of a mesh network 1231. The coordinator 1210 interacts with the IP node 1220 to establish a connection 1222 before transferring data 1226 and then closing the connection 1228. While the coordinator 1210 relies on receiving TCP message information from the IP node 1220 before forwarding such information to the TIP node 1230, the coordinator 1210 otherwise interacts with the TIP node 1230 with timing independent of the IP network 1224 timing. The coordinator establishes a connection 1232 with the TIP node 1230, segments data received from the IP node 1220 and sends the re-segmented data 1234, and then terminates the TIP connection 1236 after all the data has been sent. Both the processes illustrated in FIGS. 11 and 12 can be reversed using the same principles.

The words “herein,” “above,” “below,” and words of similar import, when used in this application, shall refer to this application as a whole and not to any particular portions of this application. Where the context permits, words in the above description or in the Appendices or attachments hereto using the singular or plural number may also include the plural or singular number respectively. The word “or,” in reference to a list of two or more items, covers all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list.

The above and attached description of embodiments of the invention is not intended to be exhaustive or to limit the invention to the precise form disclosed above. While specific embodiments of, and examples for, the invention are described above for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. Further any specific numbers noted herein are only examples: alternative implementations may employ differing values or ranges.

The teachings of the invention provided herein can be applied to other systems, not necessarily the system described above. The elements and acts of the various embodiments described above can be combined to provide further embodiments.

While the above description describes certain embodiments of the invention, and describes the best mode contemplated, no matter how detailed the above appears in text, the invention can be practiced in many ways. Details of the system may vary considerably in its implementation details, while still being encompassed by the invention disclosed herein. As noted above, particular terminology used when describing certain features or aspects of the invention should not be taken to imply that the terminology is being redefined herein to be restricted to any specific characteristics, features, or aspects of the invention with which that terminology is associated. The actual scope of the invention encompasses not only the disclosed embodiments, but also all equivalent ways of practicing or implementing the invention under the claims.

The technology can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In one embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any tangible apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can utilize electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium (though propagation mediums in and of themselves as signal carriers are not included in the definition of physical computer-readable medium). Examples of a physical computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.

A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories that provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.

Claims

1. A network device comprising:

a computer program product for implementing a transport layer, the computer program product comprising: a computer readable medium, a transport layer module residing on the medium, operable to provide connection oriented transport layer services to at least one of an application layer, a presentation layer, and a session layer; and wherein the transport layer header flags essentially consist of: SYN, ACK, PSH, and RST.

2. The network device of claim 1, wherein a connection is terminated only by the network device sending or receiving a message with the RST flag set, or by a timeout.

3. The network device of claim 1, wherein data can be transferred in a message from a receiving node containing the first set ACK flag of a connection.

4. The network device of claim 1, wherein sequence numbers are assigned only at the packet level.

5. The network device of claim 1, wherein the packet level is the minimum level of data segmentation.

6. The network device of claim 1, wherein a transport layer implemented by the transport layer module directly interfaces with a data link layer without the presence of a separate network layer.

7. A computer program product for implementing a transport layer, the computer program product comprising:

a computer readable medium,

a transport layer module residing on the medium, operable to provide connection oriented transport layer services to at least one of an application layer, a presentation layer, and a session layer; and

wherein the transport layer header flags essentially consist of: SYN, ACK, PSH, and RST.

8. The network device of claim 7, wherein a connection is terminated only by the network device sending or receiving a message with the RST flag set, or by a timeout.

9. The network device of claim 7, wherein data can be transferred in a message from a receiving node containing the first set ACK flag of a connection.

10. The network device of claim 7, wherein sequence numbers are assigned only at the packet level.

11. The network device of claim 7, wherein the packet level is the minimum level of data segmentation.

12. The network device of claim 7, wherein a transport layer implemented by the transport layer module directly interfaces with a data link layer without the presence of a separate network layer.

13. A mesh network node comprising:

at least one network device, the at least one network device comprising: a computer program product for implementing a transport layer, the computer program product comprising: a computer readable medium, a transport layer module residing on the medium, operable to provide connection oriented transport layer services to at least one of an application layer, a presentation layer, and a session layer; and wherein the transport layer header flags essentially consist of: SYN, ACK, PSH, and RST.

14. The mesh network of claim 13, wherein a connection is terminated only by the network device sending or receiving a message with the RST flag set, or by a timeout.

15. The mesh network of claim 13, wherein data can be transferred in a message from a receiving node containing the first set ACK flag of a connection.

16. The mesh network of claim 13, wherein sequence numbers are assigned only at the packet level.

17. The mesh network of claim 13, wherein the packet level is the minimum level of data segmentation.

18. The mesh network of claim 13, wherein a transport layer implemented by the transport layer module directly interfaces with a data link layer without the presence of a separate network layer.