HK1155589B - Methods and systems for dynamically configuring and managing communication network nodes at the mac sublayer - Google Patents

Description

Method and system for dynamically configuring and managing communication network nodes in a medium access control sublayer

Technical Field

The present disclosure relates generally to the management and operation of devices connected by a computer network, and more particularly to the dynamic configuration of such devices.

Background

The network device uses a protocol stack that organizes the communication software in a hierarchical plurality of layers. For example, the Open Systems Interconnection (OSI) model defines seven layers, including four upper layers for software applications and three lower layers for processing data packets. The upper layers include an application layer, a presentation layer, a session layer, and a transport layer. The three lower layers include a network layer, a data link layer, and a physical layer. Network device management is typically implemented at the upper layers of the network and, to a limited extent, at the physical layer.

The data link layer (i.e., layer 2) is responsible for ensuring node-to-node validity and integrity of transmissions. The Data Link Layer (DLL) includes two sublayers: logical Link Control (LLC), and Medium Access Control (MAC). The MAC sublayer provides an interface between the LLC sublayer and the physical layer, and controls access to the physical transmission medium within the device. The MAC sublayer functionality is typically built into the device's Network Interface Card (NIC). Each NIC is provided with a unique MAC identification number to allow data packets to be transmitted to a particular destination within the network.

In some network communication protocols, type-length-value (TLV) elements may be encoded within data packets to convey optional information. The "type" indicates the type of field represented by the "value", the "length" indicates the size of the "value", and the "value" is a variable-size set of bytes that includes payload information of the unit. Header information is added at the beginning of the data packet in order to construct a packet ready for transmission over the network.

The communication protocols of the MAC sublayer have typically provided a fixed frame format in which a set of predetermined fields appear in a predetermined order. To communicate, devices within the network must follow the same, pre-defined MAC frame format. That is, a network node cannot send commands, settings, or data unless such information transmission conforms to a previously formatted field of a MAC frame. However, these MAC sublayer protocols limit the way in which a network can be configured and operated, since they require fixed frames. Furthermore, this fixed frame architecture cannot be easily extended. Adding new MAC frame features requires significant changes to the implementation.

Disclosure of Invention

Embodiments disclosed herein utilize the MAC sublayer to dynamically switch network modes, conditions, and operations. The disclosed embodiments can provide dynamic self-reconfiguration of network nodes, dynamic changes in security configuration, dynamic switching of radio interface operations, interoperability between nodes with different MAC layer capabilities, other functions, and scalability of MAC sublayer protocols without pre-configuring firmware or software within network elements.

In some embodiments, a method for dynamically configuring a communication network at a MAC sublayer is provided. The method includes generating a data packet at a transmitting node of a network, the data packet conforming to a Media Access Control (MAC) layer protocol for network communications. The data packet includes a MAC header and a data segment, wherein at least a portion of the data within the data segment is encoded as a type-length-value element, and a value included within the element identifies a value of an operating parameter of the network. The data packet is transmitted from the sending node to the receiving node. At the receiving node, the data packet is processed at the MAC sublayer of the network protocol to fetch the units and determine the values of the operating parameters. An operating parameter within the receiving node is adjusted to conform to the determined value of the operating parameter.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention as claimed.

Drawings

FIG. 1 is a block diagram illustrating a network consistent with exemplary embodiments disclosed herein;

FIG. 2 is a block diagram illustrating an exemplary data packet consistent with the exemplary embodiments disclosed herein;

fig. 3 is a flow chart illustrating a method for dynamically configuring a communication network node consistent with exemplary embodiments disclosed herein; and

fig. 4 is a block diagram illustrating exemplary embodiments disclosed herein.

Detailed Description

Fig. 1 is a block diagram illustrating an example of a network 100, the network 100 including a plurality of nodes 120 connected by communication links 140, which may be wired links, fixed wireless links, or mobile wireless links. In network 100, messages may be segmented into data packets, such as data packet 130, and transmitted according to packet switching protocols, such as Transaction Control Protocol (TCP)/Internet Protocol (IP), x.25, and frame relay. Various embodiments of network 100 may be connected to another network, include one or more other sub-networks, and/or be a sub-network within another network. Several embodiments disclosed herein may be applicable to wireless networks; such as networks utilizing the 802.15 or 802.16 standards and the WCDMA/CDMA 20003G standard.

In some embodiments, network 100 is a wireless smart grid (smart grid) network that monitors and controls various nodes 120, nodes 120 being devices used to generate, distribute, monitor, and/or manage power services. These devices may connect the user meters and the utility grid origination/distribution points to a set of network management servers (e.g., a control center) via a combination of wireless networks, access points (e.g., gateways), and/or Wide Area Networks (WANs).

As shown in fig. 1, node 120A may generate and transmit a data packet 130 to node 120B via a communication channel 140A. Node 120 may be any intelligent device connected to network 100 having hardware and software for transmitting and receiving data packets and having a corresponding Media Access Control (MAC) identification number. For example, node 120 may be a general purpose computer, a server, a network device (e.g., a gateway, switch, repeater, router), or an application specific device (e.g., a home meter, remote control). Node 120 may further include an electronic data processing system or processor (not shown) that executes computer instructions of various software modules related to controlling node 120 and data packet transfers therebetween, the computer instructions being stored within a computer readable storage device (e.g., random access memory, read only memory, flash memory, magnetic memory, or optical memory).

For example, as shown in fig. 1, the node 120 may also include various configuration modules 125 (also referred to as "control modules") that manage the node's communication within the network 100. For example, configuration module 125A may process, store, and retrieve parameters for controlling and configuring communications, functions, and capabilities of node 120A. Further, configuration module 125A may store and receive information regarding other nodes within network 100. Based on the communication parameters, configuration module 125A may determine whether node 120 should request information from other nodes or update its configuration. Via configuration module 125A, node 120A may also trigger other nodes 120B and 120C to perform some action, such as updating their respective software and/or firmware.

Although the configuration module 125 is described as a single software module, the configuration module 125 may be implemented as a hardware device, a combination of hardware and software, or multiple software modules to provide the aforementioned functionality of the configuration module 125. Furthermore, as described in more detail below, such configuration-related information may be exchanged between nodes using type-length-value (TLV) elements at the MAC sublayer.

The use of variable length TLV packets in the MAC sublayer may provide several benefits. First, variable length TLV packets may provide flexibility to dynamically and selectively add new features to the protocol to enable new or modified network functionality (e.g., protocol extensibility). Additional command types or features not initially included within the protocol may be added at any time in a backward compatible manner. For example, a network node that knows the latest TLV type definition included in a data packet will process the TLV's respective payloads. Other nodes that do not recognize the specified type can still decode the length field and skip the unrecognized TLV and process other TLVs within the packet. TLVs with recognized types are processed and unrecognized types are skipped.

At the same time, the variable length TLV packet allows old commands from node 120 that are no longer in use to be retired (i.e., discarded and/or removed). With the fixed frame format in standard MAC protocol implementations, it is not possible to simply remove the bits or message fields used to specify the feature information if a feature is no longer used. This is because all nodes are configured to correctly construct frames for transmission using a pre-established frame format and decode the frames as they are received. If a node changes the frame structure at the time of transmission, the target node will not be able to decode the frame until the node is reconfigured to be compatible with the new frame structure. Thus, in a standard MAC sublayer protocol implementation, a node cannot interoperate with a changed frame format. However, in the MAC sublayer protocol disclosed herein, the TLV definitions that are discarded may be easily removed and/or updated. The rejected TLVs may be replaced by new TLVs having the same or different functional characteristics.

In addition, the variable length TLV packets provide a way to exchange configuration information between nodes 120. For example, node 120A may send a TLV in data packet 130 that signals node 120B to perform a firmware and/or software upgrade. TLVs may also be used as a mechanism to distribute upgrade descriptions in network 100 at the MAC sublayer. For example, by changing a set of MAC TLVs, a node 120 within the network 100 may change from a pseudo (pseudo)802.16 frame format to an 802.15.4 frame format and implement the desired network environment and functionality.

Although network 100 is depicted in fig. 1 as a simplified example and is sometimes discussed using a utility network, any network with intelligent nodes may benefit from the embodiments disclosed herein. For example, the network 100 may be a cable television network, a satellite communication network, a sensor network, and an ad-hoc (ad-hoc) wireless network.

Fig. 2 illustrates a diagram of an exemplary data packet 130 consistent with embodiments disclosed herein. The packet 130 is made up of a number of portions including a Physical (PHY) layer header 210, a Data Link Control (DLC) header 220, and a MAC Protocol Data Unit (MPDU) 230. The DLC header and MPDU together make up the MAC sublayer data packet. The packet is packaged within a PHY layer packet by adding a PHY header 210 at the beginning. A frame check sequence 240, such as a 32-bit cyclic redundancy check, is appended at the end of the packet.

In the PHY header 210, the preamble includes a sequence of binary bits that enable a receiving node, such as node 120B, to detect the signal and achieve frequency and timing synchronization with the rest of the packet, such as data packet 130, received from a source node, such as node 120A. This synchronization field is followed by a start word that includes a known sequence of binary bits that, when successfully decoded, can trigger node 120B to decode a subsequent data packet 130. The start word provides, among other features, symbol level synchronization and optimizes the autocorrelation properties in conjunction with a preamble sequence of alternating bits preceding the start word. In the case where the network 100 is a network using frequency hopping, the channel id (chid) indicates a specific channel (i.e., frequency band) on which the packet 130 is being transmitted. The length field (LEN) indicates the length of the rest of the packet 130 after the field.

DLC header 220 is the header of a MAC data packet and includes a frame control Field (FCTRL). As shown in fig. 2, DLC header 220 may include a destination MAC address (DESTMAC), a source MAC address (SRC MAC), and a DLL TLV. The destination MAC address (DEST MAC) is the unique MAC address of the packet's ultimate destination node, such as node 120B. The source MAC address (SRC MAC) is the unique MAC address of the sending node, such as node 120A.

The DLL TLVs are used to communicate information within a communication link and are processed by the DLL during the communication link. The communication link between any two nodes 120A and 120B may include, for example, the exchange of four data packets. Node 120A may first poll node 120B to inform it that node 120A has data to send and determine whether node 120B is available to receive the data. If node 120B is available, it returns an acknowledgement packet to node 120A. In a network using frequency hopping, the acknowledgement may also cause node 120B to remain on the current frequency channel to receive the data, rather than hopping to the next channel in its sequence at the assigned time. Upon receipt of the acknowledgement, node 120A sends a data packet with data intended for node 120B. If node 120B is able to successfully receive and decode the packet, it returns an acknowledgement to node 120A.

Data packet 130 may have various DLL TLVs, e.g., a protocol definable Communication Link Information (CLI) TLV, a sequence control TLV, and a Data Link Layer (DLL) Cyclic Redundancy Check (CRC) TLV. For example, one or more CLI TLVs may be utilized to communicate channel control parameters. One example may include channel parameters for a Frequency Hopping Spread Spectrum (FHSS) network, including such items as timing and synchronization. DLL CLI TLV may be used by the node 120A to communicate timing synchronization information to the neighboring nodes 120B and 120C.

DLL CLI TLV may also be used to communicate timing and priority information within the communication link. For example, DLL CLI TLV may transmit "tx priority" and "tx time" fields, which are the priority and transmission time of the next packet to be transmitted in the communication link; the "Rx priority" and "Rx time" fields, which are used to define the allowed priority and length of the response to the packet that includes the TLV. The presence of the TLV also means that a response to the packet including the TLV is expected within the communication link. If DLL CLI TLV is not present in a packet sent in a communication link, this implies that both the transmit time and the receive time are zero and that one end of the communication link intentionally terminates the communication link.

DLL CRC TLV may be used to ensure that uncorrupted packets are given to the MAC. The cyclic redundancy check may be calculated over the entire MAC/DLL portion of the packet and may be the same CRC-32 algorithm used by the MFE. Thus, when the DLL CRC is added to the packet, the resulting PHY CRC-32 should be equal to zero. This minimizes the receive processing time at the DLL because the DLL does not need to calculate the received CRC; the DLL simply checks that PHYCRC-32 is equal to zero.

Further, the DLL TLV may be used to configure sequence control parameters. One example may be a DLL sequence control TLV, which is designed for DLL segmentation and duplicate detection purposes. MAC packets submitted to the DLL may be fragmented by the DLL in order to improve the likelihood of reception.

Meanwhile, the DLC end TLV may be used to indicate the end of the DLL TLV in the packet. If the packet data is a fragment of a MAC packet, then the TLV is added because the DLL needs to see the MAC TLV to stop processing the DLL TLVs in the received packet.

Above the MAC sublayer, there are multiple applications that can submit packets down for transmission. Example applications include: network layer or IPv6, MLME, IMU (e.g., gas or water meter devices in a utility network), rf ping protocol, and others. The applications do not interact and send their packets to the MAC asynchronously. The MAC sublayer protocol disclosed herein may combine packets from these applications into a single packet on the transmit side and then demultiplex it again on the receive side. By combining these smaller packets into one PHY layer data frame, the overhead (poll-ack) messages targeting the node for each packet, as well as the extra octets added by the MAC and data link layer TLVs, are avoided.

There are two mechanisms that help achieve packet coalescing. The first utilizes TLVs to encode the beginning and end of each payload. This may cause the MAC sublayer to demultiplex the payload at the receiving side. In the case where a larger packet is fragmented, the payload of a particular application is submitted upward as soon as it is completely received, even though the rest of the packet has not been received. The second mechanism is that when the MAC performs security checking (authentication), the required security information is inserted into the packet as TLVs. Security at the MAC typically relies on computing a cryptographic function on the certificate of the node and the contents of the packet. If the MAC delivers more payload for the packet, it can simply append the payload to the end, remove the existing security TLVs, and then calculate a new security TLV. Therefore, merging multiple payloads from different applications does not result in additional authentication overhead.

There are two mechanisms that help achieve packet coalescing. The first utilizes TLVs to encode the beginning and end of each payload. This may cause the MAC sublayer to demultiplex the payload at the receiving side. In the case where a larger packet is fragmented, the payload of a particular application is submitted upward as soon as it is completely received, even though the rest of the packet has not been received. The second mechanism is that when the MAC performs security checking (authentication), the required security information is inserted into the packet as TLVs. Security at the MAC typically relies on computing a cryptographic function on the certificate of the node and the contents of the packet. If the MAC delivers more payload for the packet, it can simply append the payload to the end, remove the existing security TLVs, and then calculate a new security TLV. Therefore, merging multiple payloads from different applications does not result in additional authentication overhead.

Another aspect of the MAC TLV is that it can be used to configure the node for a particular type of operation. The network parameters may be dynamically adjusted by TLVs within MAC packets sent from the source node requesting the change to the target node that will process the TLVs to implement the requested or proposed change.

In one example, TLC may be used to request a change in modulation. The modulation parameter may be identified as, for example, TYPE 17. Known modulation techniques may be encoded as follows: 1 FSK-various embodiments with numbered symbols to specify frequency and shift frequency, such as BPSK, QPSK, 8PSK, 16PSK, and so on; 2 ASK; 3 OFDM; and 4 QAM. In this example, the TLV to be changed to QPSK would be: type is 17, Length is 2, Value is 1, 4. In another example, the TLV to be changed to OFDM would be: type is 17, Length is 1, Value is 3.

In another example, a TLV may be used to request a change in FHSS hopping sequence. The FHSS hopping sequence parameter can be identified as, for example, 18, which represents a new Seed (Seed), a number of channels, and a time slot, each of which is encoded as octets. To change to a new configuration with a new seed of 45, channel number 213 and slot time of 10ms, an example TLV for a hopping sequence change request would be: type 18, Length 3, Value 45, 213, 10. Similar examples can be constructed to implement changes with other types of parameters (e.g., timing and synchronization parameters for FHSS networks; sequence control; last gasp packet thresholds in utility networks; power management parameters; routing algorithm modifications). In response to receiving the MAC sublayer packet including these types of TLVs, node 120 may change the operating parameters specified by the TLVs according to the values included within the TLVs and operate in the new configuration. The change may be instantaneous or may specify a particular time to make the configuration change using another TLV within the packet so that all nodes 120 are reconfigured synchronously.

In yet another example, the MAC TLV may be utilized to automatically discover capabilities of neighboring nodes and/or updated MAC formats. As such, the variable length TLVs disclosed herein may enable the node 120 to adapt to the capabilities of its neighboring nodes at the MAC sublayer. For example, node 120A may send a MAC message with a TLV, referred to as a "TLV Info Req" (TLV Info request), to neighboring node 120B with the purpose of eliciting a response that includes information about the functional capabilities of node 120B and the TLVs that node 120B is capable of handling. When node 120B receives the message, it responds by passing to node 120A a MAC message having a TLV, referred to as "TLV Info Rsp (TLV Info response)" with information about all TLVs that node 120B is currently capable of handling. Thus, the neighboring nodes 120A and 120B may dynamically exchange information about each other's capabilities and/or discover common capabilities. This may enable a "configuration session" between nodes in which the nodes request and assist in the reconfiguration of other nodes within the network for additional processing and functional capabilities, compatibility, optimization, and other features. This capability enables nodes 120 within the network 100 to dynamically adapt their MAC layer packets to be compatible and optimal with their current situation. Some examples of dynamic reconfiguration of a node may be: (a) reconfiguration of security parameters to overcome or protect against any threat or violation; (b) fast modification of RF channel parameters in response to network interference environments; (c) modification of the current routing algorithm or implementation of a new routing algorithm; and (d) requests for reconfiguration from back-end office servers, as well as reports on certain types of monitoring or network information. Similarly, TLVs may be used as a mechanism to signal (to neighboring network nodes) a firmware/software upgrade, and may also be used as a mechanism to distribute a specification of the upgrade at the MAC layer.

In yet another example, node 120 may be signaled using a set of one or more TLVs in the MAC packet of node 120 in network 100 that it needs to upgrade a portion of the MAC frame to obtain the most recent code. Some examples of "recent codes" may be: new security policies, new channel optimization schemes, power scaling, routing algorithms, localized data processing software, and others. System software/firmware upgrades are routine in communications networks and are currently implemented through lengthy and resource-consuming processes.

As previously described, a configurable "policy engine," such as configuration module 125, may be included within each node 120. The configuration module 125 may indicate a threshold by which the node must determine where and how to obtain new or unknown TLV definitions. For example, based on information received from neighboring nodes, such as nodes 120B and 120C, node 120A may determine whether a predetermined threshold has been exceeded. The threshold may be, for example, a combination of the percentage of neighboring nodes that utilize the TLV and/or the number of times the node receives a new TLV. Once a node has determined to obtain information about an unknown TLV, there are two places from which the node can retrieve the information. First, the node may obtain such information from a general server located at the application layer (layer 7). Second, at the MAC sublayer (layer 2), the node can request this definition from neighboring nodes using the "TLV Info req" TLV. This TLV causes the neighboring node to respond with all TLVs known or available to it, but when a numeric variable (e.g., ID 18) is received, it sends back an XML-like description of the data included within the TLV ID-18 in the "TLV Inforeq" TLV.

The capability is not limited to obtaining TLV defined information. This also applies to any other program instructions processed by node 120 at the MAC sublayer. When a command is received to execute a particular code, a node, such as node 120A, determines whether it is processing the specified code. If not, node 120A may obtain the necessary code in one of a number of ways. First, node 120A may explicitly request the code from an external resource, such as a neighboring node (e.g., node 120C). Second, node 120A may construct the code by applying the specific values provided by the commands to a generic code template and compiling the results, e.g., in the form of TLVs. Third, node 120A may dynamically generate the code based on the functional specification provided by the command.

The configuration module 125 may be further configured to establish network-wide policies regarding which nodes 120, when and how each of the nodes 120 receives information regarding TLVs, the new TLVs themselves, and implement a new configuration context. Furthermore, the policy may be enforced network-wide, wherein the node 120 is reconfigured with new functional capabilities or network modes.

Fig. 3 is a flow chart illustrating an exemplary method of dynamically configuring a communication network. At a sending node of the network, such as node 120A, a data packet 130 is generated that conforms to a Media Access Control (MAC) layer protocol for network communications, the packet including a MAC header and a data segment (step 305). At least some of the data in the data segment is encoded as TLV elements. Further, the values included within the cell may identify the values of the operating parameters of the network. The data packet from the sending node 120A is transmitted to a receiving node, such as node 120B (step 310). At the receiving node, the data packet is processed at the MAC sublayer of the network protocol to obtain the unit and determine the values of the operating parameters (step 315). Using the information received in the data packet, the operating parameters in the receiving node 120B are adjusted to correspond to the determined values (step 320). Based on the operating parameters, configuration module 125B within node 120B may update one or more network operating parameters of node 120B.

Fig. 4 illustrates an exemplary embodiment that includes two overlapping networks 410 and 420. Both networks 410 and 420 use TLV-based MAC frame formats consistent with the present disclosure, but each network operates at a different frequency and uses different network parameters. The exemplary node 411 has mixed RF capabilities and is thus capable of transmitting/receiving at the frequencies used by the networks 410 and 420. For purposes of this example, assume that node 411 is a member of network 410 and is configured to interoperate with its neighboring nodes 413 and 414 and with server 430 utilizing gateway 412 as its egress point.

As shown in fig. 4, network 420 also includes gateway 422. If gateway 422 has full hybrid capabilities, nodes within both network 410 and network 420 may interoperate with gateway 422, including, for example, registering, obtaining an IP prefix, and fallback to central server 430 for their respective networks.

At some point, an event may cause node 411 to join network 420. For example, node 411 may periodically check for a new network, node 411 may look for a new network after failing to communicate with network 410 for a predetermined period of time, and/or gateway 412 or server 430 may instruct node 411 to join another network in special circumstances (e.g., failure, security compromise, change in node allocation, etc.). Since node 411 and gateway 422 have hybrid capabilities, they may communicate as shown by the solid lines therebetween. However, according to the present example, node 411 is not initially configured to interoperate within network 420, and thus it is not yet able to interoperate with nodes 423 and 424 within network 420, as shown by the dashed lines.

To join network 420, node 411 sends an "Info Request" TLV to gateway 422 to Request the operating parameters of network 420. In Response from gateway 422, node 411 receives an "Info Response" message with the required TLVs from 422. Node 411 processes the information received from gateway 422, e.g., using configuration module 125, to effect changes to the network operating parameters and TLV definitions of node 411, for example. Once this is done, node 411 performs discovery, registration, next (uplink) neighbor identification for routing and other operations. From this point on, node 411 becomes a fully operational node within network 420.

With the TLV-based MAC implementation disclosed herein, configuration requests that are not supported by a particular node can be automatically ignored and thus do not affect the operation of that node within the network; it continues to operate within its capabilities. The resulting lack of response to the unintelligible configuration request may be an implicit signal to the requestor that the node capability does not support the request. In which case no specific protocol is required to handle legacy nodes. In this manner, TLV-based MAC implementations may provide coexistence and interoperation of legacy nodes and newer nodes introduced (installed) within the network without specific cooperation.

Although illustrative embodiments of the invention have been described herein, the scope of the invention includes any and all embodiments having equivalent elements, modifications, omissions, combinations (e.g., of aspects across various embodiments), adaptations and/or alterations as would be appreciated by those in the art in light of the present disclosure. The limitations in the claims are to be interpreted broadly based the language employed in the claims and not limited to examples described in the specification or during the prosecution of the patent application, which examples are to be construed as non-exclusive.

While certain features and embodiments of the invention have been described, other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments of the invention disclosed herein. Although the exemplary embodiments are described with respect to certain networks, the present invention is equally applicable to other network environments having configurable intelligent nodes. It is intended, therefore, that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

Claims (22)

1. A method for communicating in a network having a plurality of nodes, the network having a plurality of communication layers including a medium access control, MAC, sublayer having an interface with a physical layer and one or more other layers, the method comprising:

receiving, by the first node from another node, TLV information corresponding to a type-length-value, TLV, definition unknown to a policy engine of the first node, wherein the TLV definition is a definition that enables the first node to process a payload of a TLV segment received by the first node;

reconfiguring a policy engine of the first node to include the TLV definition;

parsing, by the first node, one or more TLV segments from a TLV message received by the first node at a MAC sub-layer of the network; and

the configuration of the first node is modified based on processing of information included in the one or more TLV segments using TLV information of the reconfigured policy engine of the first node.

2. The method of claim 1, wherein the TLV information identifies a rejected TLV type, and

the step of reconfiguring the policy engine comprises: the definitions of the discarded TLV types are removed from the policy engine.

3. The method of claim 1, wherein parsing one or more TLV segments from a TLV message comprises:

TLV values indicating timing and priority information for the communication links are extracted.

4. The method of claim 1, wherein parsing one or more TLV segments from a TLV message comprises:

a TLV value indicating a modulation frequency for the network is extracted.

5. The method of claim 1, wherein parsing one or more TLV segments from a TLV message comprises:

a TLV value indicating timing and synchronization for the first node is extracted.

6. The method of claim 1, wherein parsing one or more TLV segments from a TLV message comprises:

extracting a TLV value indicating a frequency hopping spread spectrum hopping sequence parameter.

7. The method of claim 1, wherein parsing one or more TLV segments from a TLV message comprises:

any segments of the TLV message not known to the policy engine of the first node are skipped.

8. The method of claim 1, wherein parsing one or more TLV segments from a TLV message comprises:

a TLV value indicating a cyclic redundancy check value is extracted.

9. The method of claim 1, wherein parsing one or more TLV segments from a TLV message comprises:

a TLV value indicating a generation token parameter is extracted.

10. The method of claim 1, wherein modifying the configuration of the first node based on the processing of the information included in the one or more TLV segments comprises:

the configuration of the first node is modified from using a frame format according to the first wireless standard to a frame format according to the second wireless standard.

11. The method of claim 1, wherein the received TLV information includes TLV definitions that enable the first node to process payloads of the TLV segments to implement one or more of: security policy, channel optimization, power scaling, routing, and data processing.

12. The method of claim 1, further comprising:

a request for TLV information corresponding to the TLV definition is sent from the first node to the other node.

13. The method of claim 12, wherein sending a request for information from a first node to another node comprises:

the threshold is exceeded as determined by the first node.

14. The method of claim 13, wherein the threshold is one or more of: (i) a percentage of nodes defined using TLVs, and (ii) a number of times that the first node receives a TLV segment, wherein for the TLV segment, a TLV definition is required to enable the first node to process a payload of the TLV segment received by the first node.

15. The method of claim 12, wherein sending the request for information from the first node to the other node is performed in response to a determination that the TLV definitions are not known to a policy engine of the first node.

16. The method of claim 15, wherein the sending of the request for information from the first node to the other node is performed whether in response to an indication that the other node has TLV definitions.

17. The method of claim 12, wherein sending the request for information from the first node to the other node is based on an indication from the plurality of other nodes that there is a TLV definition for the other node.

18. The method of claim 1, further comprising the steps of:

maintaining information in a first node regarding a first frame format comprising a TLV definition that a node may use to process TLV segments in TLV messages received in accordance with a first protocol of the MAC sub-layer; and

the first frame format is adapted to the second frame format to include a TLV definition that the node can use to process TLV segments in TLV messages received in a second MAC sublayer protocol that is different from the first MAC sublayer protocol.

19. The method of claim 18, further comprising the step of:

one or more of the TLV definitions for the second frame format are received via TLV segments in TLV messages received at the node from at least one other node of the communication network.

20. The method of claim 19, wherein the first node is responsive to a request sent by the first node for information regarding the non-identified TLV segment in the data packet received by the first node.

21. The method of claim 20, wherein the first node sends the request in response to receiving a predetermined threshold number of data packets comprising the non-identified TLV segments.

22. The method of claim 18, wherein the step of adapting the first frame format to the second frame format comprises:

overriding at least one TLV definition included in the first frame format and not included in the second frame format.