Increasing Bandwidth in a Downhole Network

Abstract

A system, apparatus and method to increase bandwidth in a physically segmented downhole network are described herein.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a non-provisional application of provisional application 60/766,875, filed Feb. 16, 2006, entitled “Physically Segmented Logical Token Network” and provisional application 60/775,152, filed Feb. 21, 2006, entitled “Node Discovery in Physically Segmented Logical Token Network”, and claims priority from both provisional applications. Both of the above referenced provisional patent applications are hereby incorporated by reference herein for all they disclose.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Embodiments of the present invention relate to the fields of data processing and data communication. More specifically, embodiments of the present invention relate to methods and apparatus for increasing data communication bandwidth in a downhole networking environment.

2. Description of the Related Art

Advances in data processing and data communication technologies have led to the development of a wide variety of data communication arrangements, including but not limited to various on-chip, on-board and system buses, as well as local and wide area networks. These data communication arrangements are deployed in a wide range of applications, including but not limited data communications in harsh environments, such as oil and gas exploration.

As exploration and drilling technology matures, the need to accurately communicate data with components located in a downhole tool string is vital to continued success in the exploration and production of oil, gas, and geothermal wells. Downhole tool string configurations often incorporate multiple downhole drilling and exploration devices for reporting temperature, pressure, inclination, salinity, and other factors at or near real-time to the surface.

Due to the cost of replicating the transmission segments and the difficulty in transmitting data across the barriers, the downhole network is typically limited to only a single physical cable or communication channel, thereby limiting bandwidth. Moreover, the communication channel must be durable to withstand the extreme conditions in a downhole network.

With respect to power resources, each network node is reliant on downhole generators and other on-board power reserves, which often may not be recharged until the node is physically removed from the downhole environment. These power reserves are gradually depleted with every transmission generated or relayed by the network node. Each data transmission between network nodes typically passes through several intervening drill pipes linked in the drill string by transmission segments and uses both bandwidth and power before reaching their destination.

Unfortunately, networks associated with the downhole tool string often have unreliable connections along with the limited bandwidth and restricted power resources. A variety of factors including formation fluids, drilling mud, stress corrosion, and erosion from cuttings may contribute to the unreliability of drill string connections. As a result of these and other factors there is likelihood that various errors or data corruption may be introduced into the data or prevent/delay delivery of the data. Moreover, a network will often organize transmitted data in a manner that enables delivery to each network node, such as physical (PHY) layer frames and/or a media access layer (MAC) layer datagrams. Due to the previously identified data corruption, the PHY layer frames and/or the MAC layer datagrams commonly undergo data verification including among other things error-checking to identify corrupt data. Unfortunately, PHY frames and MAC datagrams with errors are entirely discarded by the traditional network protocols and devices, which in the downhole environment is an extremely costly result.

Accordingly, the corrosive and mechanically violent nature of a downhole drilling environment, combined with the limited ability to communicate with or to deliver power to network nodes at the bottom of the drill string are factors that make the task of providing a commercially acceptable downhole network for bidirectional communication between the surface and the components in the drill string difficult for the industry to overcome.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be described by way of exemplary embodiments, but not limitations, illustrated in the accompanying drawings in which like references denote similar elements, and in which:

FIG. 1 illustrates a block diagram of a network node data communication arrangement in accordance with various embodiments of the present invention;

FIG. 2 illustrates a block diagram of a data structure, in accordance with various embodiments of the present invention;

FIG. 3 illustrates a block diagram of a source node and a destination node data communication arrangement in accordance with various embodiments of the present invention;

FIG. 4 illustrates a network node suitable for practicing various embodiments of the present invention as presented in FIG. 1 and in FIG. 5 in further detail, in accordance with various embodiments;

FIG. 5 illustrates a downhole networking environment suitable for practicing various embodiments of the present invention;

FIG. 6 illustrates a flowchart view of a portion of the operations of a destination network node in accordance with various embodiments; and

FIG. 7 illustrates a flowchart view of a portion of the operations of a source network node in accordance with various embodiments.

DETAILED DESCRIPTION OF THE INVENTION AND THE PREFERRED EMBODIMENT

Various embodiments, described below, have been developed in response to the current state of the art and, in particular, in response to the previously identified problems and needs of downhole networks for bidirectional communication between the surface and the components in the drill string that have not been fully or completely solved by currently available systems and communication protocols for downhole networks.

Embodiments provide methods to reduce time, power, size, and computational cycles required for data communication and thereby increase available bandwidth between network nodes or access points or physical mediums on a network. As repeat latency in the network nodes is decreased available bandwidth is increased.

In at least one embodiment, a ‘token protocol’ based approach is presented, where status from attached and active node may be reported and recorded in a topology without fundamentally impacting the underlying frameworks being used by the network and enabling optimizations in addressing and delivering data being transmitted. Moreover, as transmitted data is received by all nodes in the network, error checking may also be performed by the network nodes at the NET layer, instead of or in addition to the lower layers, such as the MAC layer. More specifically, in various embodiments, each network node may avoid checking destination addresses for data at the MAC layer and further avoid performing error checking on the body of the data at the MAC layer.

In the following detailed description, reference is made to the accompanying drawings which form a part hereof wherein like numerals designate like parts throughout, and in which are shown, by way of illustration, specific embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present invention. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims and their equivalents.

Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification do not necessarily all refer to the same embodiment, but it may. The phrase “A/B” means “A or B”. The phrase “A and/or B” means “(A), (B), or (A and B)”. The phrase “at least one of A, B, and C” means “(A), (B), (C), (A and B), (A and C), (B and C) or (A, B and C)”. The phrase “(A) B” means “(A B) or (B)”, that is “A” is optional.

Referring to FIG. 1, a downhole network 100 in accordance with various embodiments is illustrated. The downhole network 100 includes a predecessor node 110, a network node 120, and a successor node 130. In one embodiment, the network node 120 receives and/or transmits data 150 in both directions in the downhole network 100. Data 150, in an embodiment, may also be generated by the network node 120 for transmission to at least one of the other nodes, selected from the predecessor node 110 and the successor node 130.

More specifically, data 150 is received from other network nodes physically positioned above and/or below the network node 120 and is then transmitted to other network nodes in the downhole network 100. In one embodiment, the network node 120 receives data 150, from an immediately coupled predecessor node 110 and transmits the data 150 to an immediately coupled successor node 130. In general, the network node 120 will transmit received data 150 to the other immediately coupled nodes, such as the successor node 130 or the predecessor node 1 10. Occasionally, an orphan node 140 in the downhole drilling string will transition to become an active member of the downhole network 100.

In various embodiments, the data 150 is organized and/or encapsulated in at least one frame 160, at least one datagram 170, and may also include at least one packet 180. Each frame may include frame header information and/or a frame payload. In one embodiment, the frame payload includes at least one datagram 170. Accordingly, in one embodiment, at least one datagram 170 is encapsulated in a single physical (PHY) layer frame 160.

In various embodiments, at least one network (NET) layer packet 180 is encapsulated in a media access (MAC) layer datagram 170. Each datagram includes datagram header information and a datagram payload. The datagram payload includes at least one packet 180. In various embodiments, each of the at least one packet 180 includes packet header information and a packet payload. The packet payload includes a portion of the encapsulated data 150.

In various embodiments, the network node 120 is configured to perform error checking of the data 150. In one embodiment, each packet 180 is configured to individually provide error checking, independent of the datagram 170 and/or the frame 160. The data verification information necessary to perform the error checking is provided for at least one of the packet header information and the packet payload containing the encapsulated data.

Referring now to FIG. 2, a data structure is shown, in accordance with various embodiments. The data 210 is organized and/or encapsulated in at least one PHY frame 220, at least one MAC datagram 230, and may also include at least one NET packet 240.

In various embodiments, each PHY frame 220 includes PHY frame header information 225 and a frame payload including the at least one encapsulated MAC datagram 230. In various embodiments, PHY frame header information 225 includes data quality verification for at least the portion of the PHY frame storing the PHY frame header information 225.

In various embodiments, each MAC datagram 230 includes MAC datagram header information 235 and a MAC datagram payload. The MAC datagram payload of the MAC data gram 230 includes at least one NET packet 240. In various embodiments, MAC datagram header information 235 includes data quality verification for at least the portion of the MAC datagram 230 storing the MAC datagram header information 235.

In one embodiment, each NET packet 240a includes NET packet header information 250 and a NET packet payload 245. The NET packet header information 250 may include a destination node identifier 251, destination port information 253, a source node identifier 255, source port information 257, and packet length information 259. The NET packet payload 245 generally includes at least a portion of the encapsulated data 210.

In one embodiment, the NET packet 240a is configured to individually provide error checking and/or data verification for at least one of the NET packet header information 250 and the NET packet payload 245, independent of the MAC datagram 230 and/or the PHY frame 220. Alternatively, one embodiment determines packet validity based on hierarchical error checking and/or data verification of PHY frame header information, MAC datagram header information, and NET packet header information followed by error checking and/or data verification of the NET packet payload.

Resynchronization of parsing of the NET packets 240 enables the system to recover uncorrupted NET layer packets 240 from corrupted MAC datagrams 230 and/or PHY frames 220. In various embodiments, a unique distance indicator, such as a hop count 270, is added to the Net packet and used for resynchronization upon detection of data corruption. As the hop count 270 in a downhole network 100 is unique for each node, it may be used to identify the node and also to provide a relative distance of transmitting node that originally generated the packet from the receiving node.

Accordingly, a modified NET layer packet 240b is generated from the Net packet 240a through data manipulation to remove naturally occurring data that also matches the unique identifier. One technique of data manipulation includes bit and/or byte stuffing. Once a value is chosen for the identifier, the other normally occurring instances of the identifier are removed and replaced by a replacement indicator to generate a stuffed packet 275. Upon reception of the data, the stuffed packet 275 may be unstuffed back to the original Net packet 240a by removing the replacement indicators and restoring the original values.

Referring to FIG. 3, a data communication arrangement between a source node 300a and a destination node 300c is shown, in accordance with various embodiments of the present invention. In one embodiment, the network node 300 is coupled to a transmission segment 350 and includes an application layer 310, network layer 320, media access layer 330, and physical layer 340.

In one embodiment, applications residing in the application layer 310 receive, generate, store, and transmit data 360. Network layer applications are configured to encapsulate/unpack data 360 of at least one packet 370. Media access layer applications are configured to encapsulate/unpack at least one packet 370 of at least one datagram 380. Physical layer applications are configured to encapsulate/unpack at least one datagram 380 of at least one frame 390. The physical layer applications are also configured to transmit and/or to receive at least one frame 390 via a transmission segment 350.

In one embodiment, a network node 300 may be configured to operate as either a source node 300a and/or a destination node 300b/300c. The source node 300a encapsulates and transmits data to at least one destination node 300c in a physically segmented logical token network. In the illustrated embodiment, the physical layer 340a of the source node 300a transmits the at least one frame 390 via the transmission segment 350. The transmission segment 350 is also coupled to a potential destination node 300b. The potential destination node 300b is configured to receive at least one frame 390 at a physical layer 340b and to transmit the received at least one frame 390 onto the next node, such as the destination node 300c.

Various embodiments of the present invention perform NET layer parsing and resynchronization, which enables each of the network nodes (e.g., 300a, 300b, and 300c) to recover NET layer packets 370 from a PHY frame 390 and/or a MAC datagram 380 even in some cases after data corruption has occurred within a portion of the PHY frame 390. More specifically, data recovery may be accomplished by parsing packets for individual links at the NET layer 320. The NET layer packet 370 is similar to the MAC layer datagram 380 in that both may include a header and a payload. In one embodiment, a cyclic redundancy check (CRC) is associated with each NET layer packet 370, so that a corrupted PHY frame 390 and/or a MAC datagram 380 may still include some recoverable NET layer packets 370. A CRC is often computed and appended by a transmitting node to a NET layer packet 370 before transmission or storage, and verified afterwards by the recipient node to confirm that no changes occurred in transit. In various embodiments, CRCs are provided for both the header and the payload of NET layer packets 370, where the MAC layer datagram 380 and PHY frame 390 only have a CRC for each respective header portion. The header for the NET layer 320 provides addressing and other information about how to handle the data in the NET payload portion of the NET layer packet 370. In one embodiment, header portion errors in either a MAC layer datagram 380 and/or a PHY frame 390 are recoverable, so that only detection of a CRC error in a NET layer packet 370 will result in the packet being thrown out.

As such, the network architecture differs from other networks in that various embodiments perform error checking using a CRC at the NET layer 320. Essentially, this configuration may allow corrupted packets to pass through the PHY layer 340 and MAC layers 330, which allows for potential recovery of data in corrupted MAC layer datagrams 380 and/or a PHY frames 390 thereby saving bandwidth by reducing retransmission and increasing the overall speed of the network. As NET layer packets 370 are exchanged between the NET layer 320 and the MAC layer 330 a CRC is inserted at the end of the header and the payload. As the NET layer packets 370 are received again from the MAC layer 330 the CRC is checked to ensure the data has not been corrupted. NET layer packets 370 with a bad CRC are thrown out. In one embodiment, error checking is performed by a NET layer CRC device.

Once data corruption has been detected, resynchronization of the parsing at the NET layer 320 enables the system to recover uncorrupted NET layer packets 370. In one embodiment, resynchronization may be accomplished by detecting a unique identifier, such as a Packet Synchronization Sequence (PSS), at the start of each NET layer packet 370. Other unique identifiers may also be provided between each MAC layer datagram 380 and/or PHY frame 390. In various embodiments, the unique identifier is generated through data manipulation to remove naturally occurring data that also matches the unique identifier. One technique of data manipulation includes bit and/or byte stuffing each NET layer packet 370. Once a value is chosen for the identifier, normally occurring instances are removed and replaced by a replacement indicator. Upon reception of the data, the replacement indicator is removed and the original value is restored. If an error is detected during reception (e.g., CRC), then scanning for the unique identifier provides various possibilities. A bit sequence matching the unique identifier will either identify the start of the next NET layer packet 370 or a corrupted value in the data stream, calculation of the CRC will determine which case is present. In this manner, the receiving node may resynchronize parsing of the NET layer 320 despite the presence of errors and/or data corruption.

In one embodiment, Zero-bit insertion, a particular type of bit stuffing, is used to ensure that a PSS doesn't incidentally appear in the contents of the PHY frame 390, MAC layer datagram 380, and/or NET layer packet 370. Once a bit sequence is selected, any naturally occurring sequence needs to be removed from the data. For example, if “01111110” was selected as the PSS, the data would need to be altered to ensure that a sequence of 6 consecutive “1” bits are not present in the frame data so as to avoid possible confusion for the PSS. In one embodiment, zero-bit insertion is used to prevent such a sequence from occurring. More specifically, if a series of five “1” bits are found in the data by the sending node a “0” bit is inserted after the fifth “1” bit, thereby limiting the maximum possible run of “1” bits to five. At a receiver node, if a series of five “1” bits is received, the subsequent “0” bit is removed to recover the original data.

When the receiver node finds “0111111” two possible outcomes may occur. To determine which, the next bit is checked. If the bit is a “0” (i.e. “01111110”) a valid PSS is assumed to have been received. If the bit is another “1” (i.e. “01111111”) then some corruption must have occurred during transmission as that data sequence cannot have been transmitted according to the selected bit sequence for the PSS. In the described example a “0” bit would have been inserted after the fifth “1” bit. Should corruption during transmission result in the PSS being received as part of the data, it is more than likely that the failed CRC would mean that both packets may be suspect to data corruption.

Referring to FIG. 4, a network node 400 is shown in further detail, in accordance with various embodiments. An exemplary downhole network node 400 suitable for practicing various embodiments as presented in FIGS. 1, 3, and 5 is shown in FIG. 4, a block diagram of a downhole network node 400 having at least one communication interface 420 and a communication module 410. The network node 400 includes at least one communication interface 420, a communication module 410, a packet router 430, a local processing module 440, and a local data acquisition module 450, coupled to each other as shown.

The illustrated communication module 410, such as a modem, may be connected to the network (see e.g., network 510 in FIG. 5) in at least two directions via transmission segments (see e.g., transmission segments 350 in FIG. 3 and/or integrated transmission drill pipe 570 in FIG. 5). However, in alternate configurations the communication module 410 may only be connected to the network 510 in one direction. The communication module 410 may modulate digital bits on an analog signal to transmit data packets from the network node 400 on the network 510 and demodulates analog signals received from the network 510 into digital data packets. In various embodiments, the communication module 410 may include a storage medium 470 to temporarily store data in conjunction with transmission.

As previously indicated, a network node 400 may also employ a timing device to calculate whether time-out thresholds have been reached. The timing device may include multiple timers individually assigned to each communication interface 420 or to the communication module 410 in general.

The network node 400 may comprise a packet router 430 that receives packets from the communication module 410 and forwards them to one or more of a local processing module 440, a local data acquisition module 450, or a peripheral port 460. Packets to be transmitted on the network 510 may also be forwarded to the communication module 410 from the packet router 430.

The downhole network node 400 includes a peripheral tool port 460, which allows the downhole network node 400 to collect data from associated tools, packetize the tool data and transmit it to the top of the well.

In one embodiment, a downhole network node 400 includes a suitable portable power source 480. Often the downhole network node 400 will need to be self-reliant on multiple battery packs 490 for power requirements. In one embodiment some of the battery packs 490 may be allocated to individual components of the downhole network node 400 based in part on the function provided by the component requesting power. For example, a portion of the battery packs 490 could be dedicated to transmitting received packets (e.g., 410 and 470) to the next node. Another portion could be dedicated to maintaining the local processing 440 and related components (e.g., 430, 450, and 460). In one embodiment, an attached tool may either draw power from the node or provide a source to recharge the batteries.

Referring to FIG. 5, a drilling operation 500 with a downhole networking environment suitable for practicing various embodiments of the present invention is shown. Accordingly, when drilling boreholes into earthen formations, the drilling operation 500 as shown in FIG. 5 may be used. The drilling operation 500 may include a drilling rig 505, an integrated downhole physically segmented logical token network 510, and a tubular drill string 560 having a bottom hole assembly 580. The bottom hole assembly 580 typically forms the bottom of the drill string 560, which is typically rotatably driven by the drilling rig 505 from the surface. In addition to providing motive force for rotating the drill string 560, the drilling rig 505 also supplies a drilling fluid under pressure through the tubular drill string 560 to the bottom hole assembly 580. Other components of the bottom hole assembly 580 include a drill collar 575, a drill bit 590, and various other down hole components. In operation, the drill bit 590 is rotated and weight is applied. This action forces the drill bit 590 into the earth, and as the bit is rotated, a drilling action is effected.

The downhole physically segmented logical token network 510 includes a first end node and/or a top node 520, a plurality of transmission segments integrated into the drill pipe 570, a plurality of intermediate nodes and/or middle nodes 530 and 540, and the second end node and/or a bottom node 550. The downhole network 510 provides an electrical interconnection between the top node 520 and the bottom node 550. The top node 520 may, in accordance with at least one embodiment, be a component of a server 515. The server 515 is positioned near the top of the well in one embodiment and may relay reconstituted well information gathered from various components in the downhole network 510 to a variety of interested client computing devices across an area network, such as the Internet, using traditional methods known in the art.

The downhole network 510 operates similar to the previously described network of FIG. 1, although features may be described in a more directional nature, for example, in one embodiment of the downhole network 510 a frame may include data associated with a logical token that may be passed up and down the downhole network 510. In one configuration, a first token may be designated as a down-token, and a second token may be designated as an up-token. Other directional adaptations include referring to the first end node as a top end node and the second end node as a bottom end node. As such, in one embodiment, the down-token may be generated by the top node 520 that the individual nodes (530, 540, and 550) are cyclically and/or periodically allowed to claim. In one embodiment that tries to equalize the number of transmission opportunities for each node, the up-token is a logical token that only the top node 520 is allowed to claim.

Although the down-token has been characterized in one embodiment to be an equivalent to the first token and the up-token is characterized as an equivalent to the second token, it is clear to one of skill in the art that other characterizations are possible and should be considered within the scope of the instant invention. For example, the roles of the up and down tokens could be reversed. Moreover, the up-token and the down-token could be functionally the same logical token. In such a configuration, a directional modifier may be assigned at each node based in part on which communication interface received the token.

As previously indicated, a downhole network 510 is often a difficult and or discontinuous operating environment. For example, as the well increases in depth, new tubular drill pipe is added to the drill string below the top node 520, temporarily interrupting data communications between the nodes. Additionally, portions of the drill string may become temporarily unavailable due to mechanical stresses related to drilling operations. As a result in one embodiment, each intermediate node (530 and 540) may become the bottom node 550 when no data and/or token are received from a successor immediately coupled node for a designated time period based in part on the number of nodes in the downhole network 510.

In various embodiments, the top node 520 is configured to selectively generate another down-token even if the up-token is not received within a designated time period. The designated time period is often based in part on the number of known active nodes in the downhole network.

Depending on the importance of the data being collected by the portion of the network 510 in the bottom hole assembly 580, temporarily interrupting data may be unacceptable. In these situations the network may employ multiple sub-networks to divide the network 510 and continue data communication. For example the illustrated network 510 may be divided into two sub-networks, the portion of the network 510 in a bottom hole assembly 580 and the top portion of the drill string 560 associated with a sub-network 585. In various embodiments, an entire sub-network, e.g. all the nodes of network 510, may transition to an orphan operational status to conserve power or preserve data through active manipulation of timing devices associated with the end node of the sub-network.

Turning now to FIGS. 6-7, the particular methods of the invention, in accordance with various embodiments, are described in terms of computer firmware, software, and hardware with reference to a series of flowcharts. In various embodiments, portions of the operations to be performed by network devices may constitute state machines or computer programs made up of computer-executable instructions. Describing portions of the operations by reference to a flowchart enables one skilled in the art to develop programs including instructions to carry out the illustrated methods on suitably configured network devices (e.g., a processor of the network device executing instructions from a computer-accessible media).

In various embodiments, the computer-executable instructions may be written in a computer programming language or may be embodied in firmware logic. If written in a programming language conforming to a recognized standard, such instructions can be executed on a variety of hardware platforms and for interface to a variety of operating systems. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the embodiments as described herein. Furthermore, it is common in the art to speak of software, in one form or another (e.g., program, procedure, process, application, etc.), as taking an action or causing a result. Such expressions are merely a shorthand way of saying that execution of the software by a network device causes the processor of the computer to perform an action or a produce a result.

Referring to FIG. 6, a portion of the operations of a network node operating as a potential destination node 600 is shown, in accordance with various embodiments. The network node operating as a potential destination node 600 receives data in block 610. The received data is modified in block 620 to include relative distance from source node updated by the network node operating as a potential destination node 600. In one embodiment, the data is encapsulated in at least one frame having at least one datagram having at least one packet. The potential destination node 600 begins to transmit the modified received data in block 630. In one embodiment, transmission of the frame to the next node may begin as soon as the header is modified by the potential destination node 600.

The network node operating as a potential destination node 600 determines the desired destination of data in block 640. In one embodiment, each frame is parsed into at least one datagram, and each datagram is parsed into at least one packet of the received data in block 650. The received data is verified in block 660. In one embodiment, the packet having packet header information and a packet payload also includes data quality information to verify the received data. The data quality information may be associated, individually or collectively, with the packet header information and/or the packet payload. In one embodiment, the destination identified in the packet header information is verified first by the network node operating as a destination node 600 in block 640 and if the current node is a valid destination, the contents of the packet payload is subsequently verified in block 660. Alternatively, both the packet header information and the packet payload could be verified together.

In one embodiment, the packet data quality information is independent of any data quality verification provided by encapsulated datagram header information and/or frame header information. This separation allows the network node operating as a potential destination node 600 to selectively ignore data errors in the datagram header information and/or the frame header information, if recoverable data is available in the packets associated with the corrupted frame and/or datagram.

Referring to FIG. 7, a portion of the operations of a network node operating as a source node 700 is shown, in accordance with various embodiments. In block 710, the network node operating as a source node 700 broadcasts a request for status information to other active nodes on the network. In one embodiment, the network node operating as a source node 700 is a server node and is positioned at the top of the well/downhole network. In one embodiment the request includes use of a status token to request responses from attached nodes. As responses are received in block 720 by the network node operating as the source node 700, the information is used to maintain a corresponding network topology table in block 730.

In one embodiment, the topology table may include a short network identifier (NID) for local communication in the downhole network, a longer global identifier (GUID) for addressing the node from outside the downhole network, and a unique relative distance between the source node 700 and each node. The source node 700 verifies the local identification in block 740, the relative distance in block 750, and the global identification in block 780. In the downhole environment, the relative distance, such as a hop counts and/or timestamps, may be used as a unique reference for each node. In one embodiment, the NID is a unique number that identifies the node on the downhole network and may be used for addressing the link from within the network. The GUID is a larger unique number than the NID and identifies the node outside of the downhole network.

A top-hole interface (THI) associated with the source node 700 maintains a topology table to map each node's GUID to the node's NID. The topology table may update the relative position of nodes based on the received responses to the information request. Upon detecting topology changes in block 770, the source node 700 periodically generates and distributes the detected changes in blocks 780 and 790 to attached software components outside of the downhole network. In one embodiment, a message or command may be sent from outside to a node of the downhole network via the THI. The THI translates the GUID into the respective node's NID and the command into a port number and payload, and passes the packet(s) down the downhole network. NET packets with a NID different from the node's NID are ignored by the NET layer of the potential destination nodes. In various embodiments, the port numbers may specify a specific function to be performed using the information in the payload. Each device above the NET layer recognizes port numbers that correspond to functions performed by the device. These devices typically only use packets with recognizable port numbers and ignore others.

Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art and others, that a wide variety of alternate and/or equivalent implementations may be substituted for the specific embodiment shown in the described without departing from the scope of the present invention. This application is intended to cover any adaptations or variations of the embodiment discussed herein. Therefore, it is manifested and intended that the invention be limited only by the claims and the equivalents thereof.

Whereas the present invention has been described in particular relation to the drawings attached hereto, it should be understood that other and further modifications apart from those shown or suggested herein, may be made within the scope and spirit of the present invention.

Claims

1. An apparatus comprising:

at least one communication interface configured to connect the apparatus to a physically segmented logical token network; and

a communication module, coupled to the at least one communication interface, configured to encapsulate data with packet header information in at least one packet and to encapsulate the at least one packet with datagram header information in at least one datagram and to encapsulate the at least one datagram with frame header information in a frame, the communication module having a storage medium to temporarily store the frame, with each packet including at least a portion of the data and providing at least one of:

(a) destination address identification in the encapsulated packet header information of the packet, independent of whether any destination address identification is provided in the encapsulated datagram and/or frame header information; and

(b) data quality verification in the encapsulated packet header information of the packet, independent of whether any data quality verification is provided in the encapsulated datagram and/or frame header information.

2. The apparatus of claim 1, wherein the frame is associated with a physical layer of a communication protocol, and each datagram is associated with a media access control layer of the communication protocol.

3. The apparatus of claim 1, wherein the at least one communication interface is configured to transmit data received from a node immediately preceding the apparatus on the physically segmented logical token network, to a node immediately succeeding the apparatus on the physically segmented logical token network, before the apparatus determines a destination and/or quality of the received data.

4. The apparatus of claim 1, wherein the data quality verification includes at least one of length information, parity information, and dynamic error checking and correcting information.

5. The apparatus of claim 4, wherein the communication module is configured to determine data quality of received packets based on data quality verification provided in packet header information encapsulated in the received packets, regardless whether data quality verification is already provided in the datagram header information and/or the frame header information encapsulated in a received datagram and/or frame encapsulating the received packets.

6. The apparatus of claim 1, wherein the destination address identification includes a local network identifier of a destination node without a global device identifier of the destination node.

7. The apparatus of claim 1, wherein each packet further provides origination address identification independent of whether origination address identification is provided in the encapsulated datagram and/or frame header information.

8. The apparatus of claim 7, wherein the origination address identification includes a local network identifier of a source node and/or a relative distance of the source node from the apparatus.

9. A communication arrangement, comprising:

a source node configured to encapsulate data in at least one packet, the at least one packet encapsulated in a datagram, the datagram encapsulated in a frame, each packet individually providing addressing and/or error checking for the encapsulated data independent of the datagram and/or the frame; and

at least one destination node coupled to the source node to receive the data, the source and destination nodes employ at least a token to facilitate data communication among the nodes in a physically segmented logical token network.

10. The communication arrangement of claim 9, wherein a server node is selected from the group of the source node and the at least one destination node.

11. The communication arrangement of claim 10, wherein the server node receives all data transmissions and generates a topology table based in part on the received data.

12. The communication arrangement of claim 11, wherein the topology table identifies the operational state of each node in the physically segmented logical token network.

13. The communication arrangement of claim 10, wherein the server node initiates a periodic census of the active network nodes and in response each active destination node transmits a packet to the server node including node identification information.

14. The communication arrangement of claim 13, wherein the node identification information includes a local network identifier associated with the active destination node and a relative distance to the source node.

15. A method comprising:

receiving a frame containing encapsulated data and frame header information at a network node from a node immediately preceding the network node on a physically segmented logical token network; and

prior to determining a destination for the encapsulated data contained in the received frame, transmitting the received frame to a node immediately succeeding the network node, including a modified frame header information, if any.

16. The method of claim 15, wherein the modified frame header information includes a relative distance to a source node.

17. The method of claim 16, further comprises incrementing the relative distance in the modified frame header prior to transmitting the received frame to the node immediately succeeding the network node.

18. The method of claim 15, wherein the receiving the frame further comprises receiving a network access authorization to access and to transmit at least one frame on the physically segmented logical token network.

19. The method of claim 18, wherein the network access authorization is a token.

20. The method of claim 19, wherein the token determines whether to modify frame header information to govern future network access and transmission by the succeeding node.

21. The method of claim 15, wherein the encapsulated data includes at least one encapsulated packet encapsulated within an encapsulated datagram encapsulated within the received frame.

22. The method of claim 21, further comprises verifying quality of the encapsulated data within the encapsulated packet independent of any data quality verification provided by the encapsulated datagram and/or the received frame.

23. The method of claim 22, wherein the verifying quality of the encapsulated data is performed subsequent to the transmission of at least part of the frame header information.

24. The method of claim 21, further comprises determining a destination for the encapsulated data independent of header information associated with the encapsulated datagram and/or the received frame.

25. The method of claim 24, further comprises determining whether to transmit the received frame prior to the determining the destination for the encapsulated data.

26. The method of claim 24, wherein the determining the destination is performed subsequent to the transmission of at least part of the frame header information.

27. The method of claim 15, wherein the determining whether to transmit the received frame is based on a topological position of the network node on the physically segmented logical token network.