Method and system of providing ip-based packet communications in a utility network

1/41

METHOD AND SYSTEM FOR PROVIDING IP-BASED PACKET COMMUNICATION IN A PUBLIC UTILITY SERVICE NETWORK

BACKGROUND Field of Invention

The field of the invention relates generally to systems for controlling and delivering consumable goods, and more specifically, to IP-based packet communications systems for monitoring, controlling, and delivering consumable goods.

Related Background

Automated Meter Reading (AMR) systems and Automated Meter Infrastructure (AMI) systems provide services and capabilities to monitor and/or report the usage (or consumption) of a consumable good, such as water, electricity, gas, etc. Such systems provide communication between a consumable good meter and one or more systems for reporting, billing, etc. Commodity metering information, as well as other information, is typically reported from network devices associated with the meters to reporting and billing systems.

The present invention seeks to overcome the limitations of conventional public utility service networks.

BRIEF DESCRIPTION OF FIGURES

Figure 1 is a generalized block diagram of a computer-based system that can be used to implement the present invention, in accordance with one embodiment of the invention.

Figure 2 is a generalized block diagram of a computer-based system that can be used to

2/41 implement the present invention, according to an embodiment of the invention.

Figure 3 is a generalized flow diagram illustrating a process for providing network addresses to nodes in a local area network, in accordance with one possible embodiment.

Figure 4 is a generalized communication flow diagram illustrating the registration of a nodal device with an access point, in accordance with one embodiment of the invention.

Figure 5 is a generalized block diagram illustrating the registration of a rechargeable hybrid car with an access point, in accordance with one embodiment of the invention.

Figure 6 is a generalized block diagram of a node as may be found in a communication network, in accordance with one embodiment of the invention.

Figure 7 is a generalized block diagram of an access point as might be found in a communications network, in accordance with one embodiment of the invention.

Figure 8 is a generalized backend system block diagram as might be found in a communications network, in accordance with one embodiment of the invention.

Figure 9 is a generalized block diagram illustrating a utility node subnet, according to one possible embodiment.

Figure 10 is a generalized block diagram illustrating a network where an IPv4 tunnel connects to an IPv6 LAN and an IPv6 backend system, according to a

3/41 modality of the invention.

Figure 11 is a generalized block diagram illustrating the flow of packets between the access point associated with the IPv6 LAN and the BOS over the IPv4 WAN, in accordance with one embodiment of the invention.

Figure 12 is a generalized block diagram illustrating a network where IPv6 packets are passed through an IPv4 WAN, according to one possible embodiment.

Figure 13 is a generalized block diagram illustrating a network where IPv4 packets are passed through an IPv6 LAN, according to one possible embodiment.

SUMMARY

The present invention provides a system and method for IP-based communication in a utility network. A node within the utility network may undergo a discovery process to identify its neighbors and wireless LAN access points that may provide egress from the LAN. The node then establishes a set of optimal routes to the preferred access points for egress via the next-hop neighboring nodes that offer the lowest path cost. The node can send a registration request to one or more access point devices. An IP network address prefix of the access point device network address received from one or more access point devices is used by the end node to programmatically generate a unique network address for the utility node. The end node

4/41 utility node registers with a DNS server. Messages sent to the utility node are routed through the access point corresponding to the prefix used to generate the network address for the utility node. The network address for the utility node and the access point may be IPv6 addresses, and the network address prefix may be an IPv6 prefix.

DETAILED DESCRIPTION

The present invention is described in the context of a specific embodiment. This is done to facilitate understanding of the features and principles of the present invention and the present invention is not limited to that embodiment. Specifically, the present invention is described in the context of a system for remotely reading, controlling and managing electronic devices in a public utility network. The present invention is applicable to other systems for network-based management of electronic devices and meters of consumable goods.

The exemplary embodiment provides a network-based system and method of monitoring and controlling a utility meter in a utility network.

Figure 1 is a generalized block diagram of a utility network 100 that may be used to implement embodiments of the present invention. Utility network 100 may include one or more electronic devices 101. In one embodiment,

5/41 preferred, the electronic devices 101 may be connected via a wireless local area network (LAN) 102. In the example of a utility service network, the LAN may be a neighborhood area network (NAN) corresponding to a service area or neighborhood for the utility company. As shown in the exemplary embodiment, multiple LANs may be used, which may or may not overlap, such that a given electronic device may be connected to (or be part of) only one wireless LAN or multiple wireless LANs. The electronic devices may be any type of electronic device. Examples of electronic devices include utility nodes, which may include a utility meter or may connect to a utility meter. A utility meter is a device that is capable of measuring a metered quantity, typically a consumable good such as electricity, water, natural gas, etc. Utility nodes that connect to a utility meter may include a network interface card (NIC) for communicating over a network, and may include one or more RF transceivers for communicating with one or more wireless LANs. Other examples of electronic devices include communications devices such as signal converters (as may be used in cable television or satellite television provision), household appliances (e.g. refrigerator, heater, light(s), cooking appliances, etc.), computers or computing devices (e.g.

6/41 game consoles, storage devices, PCs, servers, etc.), network operating devices such as relays, gateways, access points, routers, or other network operating devices, telephones or mobile phones, battery storage devices, transportation devices, transportation vehicles (e.g.: an electric or hybrid car or other vehicle), entertainment devices (e.g., TVs, DVD players, set-top boxes, game consoles, etc.), or other device that may be found in a home, office, highway or parking lot, or other location. Relays may handle communication between electronic devices 101 and the wireless LAN 102. For example, a relay could provide communication between the electronic device and the wireless network infrastructure. Unless otherwise noted, other devices on the network such as meters, electronic devices, gateways, etc. can also perform as relays, and relays can perform the functions of other devices or software on the network.

The wireless LAN 102 may be any type of wireless network, and may utilize any frequency, communications channel, or communications protocol.

LANs 102 are typically connected to one or more access points (APs) 103. A given LAN may be connected to only a single AP, or it may be connected to two or more access points. Access points 103 may be connected to one or more wide area networks (WANs) 104. WANs 104 may be connected to one or more backend systems (BOSs) 105. The backend system

7/41 may handle various business or management tasks, including participation in the collection of metering information, managing metering devices, security for the network, or other functions as may be desired in an ANI network. Examples of back-end systems include billing and accounting systems, proxy servers, power outage detection systems (as may be used in a utility network), data storage systems, etc.

Nodes within a communication network, which may be a LAN or a WAN, or a combination of both, may communicate using one or more protocols. Nodes may include an electronic device, a relay, an access point, a router, or a BOS. Some nodes may be capable of communicating using IPv6, some may be capable of communicating in IPv4, while some may be capable of communicating in either IPv4 or IPv6. Some nodes may be able to encapsulate IPv6 packets within an IPv4 packet. Additionally, some nodes may be able to establish an IPv4 tunnel through an IPv6 network. Communication between nodes is described more fully below.

ASSIGNING AND REGISTERING NETWORK ADDRESSES IN COMMUNICATION NETWORKS

Figure 2 is a generalized block diagram of a communications network including a LAN 200 and LAN 206. The LANs connect nodes 202 and access points 201. As shown, LAN 200 has two access points, and LAN 206 has one access point. A domain name server (DNS) 203 is connected to LAN 200 and LAN 206 through

8/41 from access point 201 to a communication network 204. In the presently preferred embodiment, DNS server 203 is capable of receiving and processing dynamic updates, thereby providing a dynamic DNS service. Dynamic DNS updating is done in accordance with IETF RFC 2136. Communication network 204 may be any type of communication network including, without limitation, a LAN, WAN, wireless private network, fixed-line private network, virtual private network, etc. In the presently preferred embodiment the communications network 204 is a wide area network, and may use one or more communications protocols such as IPv4 or IPv6. One or more computing devices 205 connect to the communications networks 204. A message to a node 202 from the computing device 205 may be sent using the network address for the node. The computing device 205 may be any device, combination of devices, network management system, server, backend systems (BOS), computers, network devices, communication devices, application or software components that is capable of communicating with an access point or node via the communication network 204. A second LAN 206 may also be connected to the DNS server 203 and the communication network 204. The DNS server may be dedicated to a single LAN, or two or more LANs may share a DNS server. As shown, LAN 200 and LAN 206 do not overlap in that none of the nodes, and none of the access points shown are members of both LAN 200 and LAN 206. Alternative embodiments may have one or more LANs that overlap, with one or more nodes and/or access points common to one or more LANs. Embodiments

9/41 alternatives may have additional LANs, which may or may not overlap with each other. In the presently preferred embodiment, the network address of a node is obtained according to the process described in connection with Figure 3 below.

The DNS server 203 maintains the network addresses for the LAN network nodes with which it is associated. As discussed above, the DNS server may be associated with one or more LANs and maintain the network addresses of nodes within one or more LANs. In a preferred embodiment, the node registered with the various access points may have at least as many network addresses. The network addresses for the nodes may be included in the DNS server, or node route record. Additionally, the DNS server may also maintain address allocation information such as a node address allocation indicator (or node preference indicator). Table 1 below shows some of the information that may be included in maintaining network addresses for nodes on a LAN. Resource records maintained by the DNS server may include:

Table 1

<td>Resource Record Type</td><td>Node Network Address</td><td>Node Name</td><td>Node Address Preference Indicator</td>

<td></td><td>ADDR1</td><td></td><td> 50</td>

<td>AAAA</td><td>ADDR2</td><td>MAC1</td><td> 30</td>

<td></td><td>ADDR2</td><td></td><td> 10</td>

<td>AAAA</td><td>ADDR4</td><td>MAC2</td><td> 80</td>

<td>AAAA</td><td>ADDR5 ADDR6</td><td>MAC3</td><td> 44 20</td>

As illustrated in Table 1, in the presently preferred embodiment the node name is the MAC address of the node. However, other embodiments may utilize other names for the node, which may or may not include or be based on the MAC address of the node.

10/41 MAC address. Additionally, the Resource Record (RR) Type in Table 1 may be an IPv6 type.

Information in the route log may be updated according to multiple criteria, including periodically or in the event that one or more criteria are met.

For illustration purposes, only one DNS server is shown and discussed below. Alternative arrangements, however, may utilize multiple DNS servers.

Alternative embodiments of DNS resource records may include additional information or may exclude some of the information included in Table 1. Additionally, although Table 1 includes information about only three nodes, alternative embodiments of a route record could have information about a greater or fewer number of nodes. Although Table 1 includes up to three network addresses for a given node, alternative embodiments of a routing record can have any number of addresses per node.

Figure 3 is a generalized flow diagram of a process 300 for obtaining a network address of a node. In step 301 a node intending to send a packet or message to a node makes a DNS resolution request to a DNS server. The DNS resolution request includes a node identifier, typically the name of the node. The node identifier may be any combination of letters, numbers, symbols, or characters. As described above in connection with Table 1, in a presently preferred embodiment the node identifier is the MAC address of the intended node. As shown in Table 1, the source or requesting node includes information specifying the

11/41 node identifier, the node's network address, the network address preference, etc. In step 302 the DNS server receives the DNS resolution request for the intended node. In step 303 the DNS server responds with a network address for the node associated with the node identifier. In the presently preferred embodiment, the network address is an IP address. In a presently preferred embodiment, the AAAA resource record refers to an IPv6 address. The IPv4 resource record (RR) can be of type A, PTR, CNAME. The DNS server can have more than one network address for a given node. For example, multiple IPv6 addresses can be associated with each node. with a given node (or access point, or BOS, or any other device on a network). If multiple addresses are associated with a given node, in step 302 the DNS server may provide all available network addresses for a specific RR. Alternatively, the DNS server may select a subset of the network addresses associated with the intended node. For example, the DNS server may choose an address from 32 C 22 LX 2. 2 IC U 2. 22 ní^L 22 Eí U çü Lf l— 2. £2 2. 2. LZ Ê; áí 22 212. X— a subset of network addresses associated with the intended node is selected, the selection may be based on a connection cost, a predefined selection criterion, a policy (e.g., the electronic device intending to exchange messages with the node, the type, size or priority of the message, some aspect of the node's use of the message, or the nature of the network device, e.g.: a server, a network management system, a billing system, a

12/41 power outage management system, a utility management system, etc.) or from some other criteria. If multiple network addresses are provided in the DNS resolution response, the response may also include the corresponding node address preference indicators. In step 304 the node receives the DNS resolution response from the DNS server. In step 305 the node sends its message using a network address received from the DNS server.

The address used to send the message from the node and/or electronic device to the intended node or electronic device may correspond to one or more access points. For example, in an IPv6 LAN the network address would typically be an IPv6 address. In the case of more than one access point, the IPv6 prefix of the network address may be associated with a particular access point. In this way, the IPv6 network address can allow a given access point to be used to transmit a message to a network destination. If a node is on a LAN with multiple access points, the node may have more than one IPv6 address associated with it.

Example 1 - Multiple Ingress using IPv6 Network Addressing

The present example has a given node with a node name of Node 1. Node 1 has two IPv6 network addresses associated with it. The route log entry for Node 1 might read:

DDNS Route Record

<td>Node Name</td><td>Resource Record Type</td><td>Node Network Address</td><td>Address Preference Indicator</td>

/41

<td></td><td></td><td></td><td>of Node</td>

<td> ....</td><td> ....</td><td> ....</td><td> ....</td>

<td>MAC1</td><td>AAAA.</td><td>2001:2105:20ae:1:225:3400:208:aa03 2001:2105:20ae:2:225:3400:208:aa03</td><td> 50 30</td>

<td> ....</td><td> ....</td><td> ....</td><td> ....</td>

Node 1 connects to a communications network through two access points: API and AP2. API is associated with the IPv6 prefix 2001:2105:20ae:1::/64 and AP2 is associated with the IPv6 prefix 2001:2105:20ae:2::/64 .

A network device, for example a backend system which manages power outage detection, intending to send a message to Node 1 might receive the network address associated with Node 1 from the DNS server's routing record (or it might receive both network addresses). A message sent from the power outage detection system to Node 1 using the network address with prefix 2001:2105:20ae:2::/64 would be forwarded through AP2. A message sent from power outage detection system 15 to node 1 using network address with prefix 2001:2105:20ae:1::/64 would be forwarded through API.

Figure 4 is a generalized communications flow diagram illustrating the process 400 for registering a nodal device with an access point. Registering a nodal device for a network address may apply to any network address format or protocol. In a presently preferred embodiment, the LAN may be using IPv6 protocols (either exclusively or in parallel with IPv4 protocols). For purposes of discussion, process 400 will describe the nodes of a wireless LAN using IPv6 network addresses. In one embodiment presently

14/41 preferred, Node M initiates a discovery process and identifies its neighboring nodes and access points of one or more LANs that provide egress and ingress. Node M may additionally initiate a forwarding analysis to identify a preferred set of one-hop neighbors that provide egress through one or more access points at the lowest path cost. It may then begin the registration process with one or more APs and affiliated DNS servers. At 401 the Node M sends a Layer 2 registration message to an access point AP. At 402 the AP responds with a Layer 2 confirmation message including an IPv6 prefix which is associated with the AP. Additionally, the confirmation message may include configuration information. In a presently preferred embodiment, the configuration information includes information that allows the Node M to register with a DNS server. In another embodiment the AP may represent the DNS request on behalf of Node M. At 403 Node M receives the Layer 2 acknowledgement message and sends a Layer 3 IPv6 registration message to the DNS. In the currently preferred embodiment, the IPv6 registration message to the DNS includes the IPv6 address for Node M, which uses the IPv6 prefix received from the AP and a unique IPv6 suffix to complete an IPv6 address for Node M. This is done consistent with the stateless autoconfiguration steps of RFC 2462. In a preferred embodiment, the IPv6 suffix is ​​based on the MAC address of node M. Alternative embodiments may use other suffixes not based on the MAC address to create a unique IPv6 address for node M. Note that the IPv6 address for node M need not be globally

15/41 singular.

At 404 a layer 3 confirmation message is sent from the DNS to node M and received by node M at 405. The layer 3 confirmation message may include confirmation of node M's registration with the DNS server, and may include additional information.

Although process 400 shows only one node registering with one access point, in the currently preferred embodiment all nodes would register with at least one access point. Additionally, in a currently preferred embodiment nodes would register with more than one access point on their LAN in the event that there is more than one access point on the LAN associated with the node. A node may even register with all access points on the LAN with which the node is associated.

In the presently preferred embodiment, a given node may have more than one unique IPv6 address associated with it. If, as described above, a node's IPv6 address is determined from an access point's IPv6 prefix and a unique component (e.g., the node's MAC address), then if the node registers with multiple access points the node will be associated with multiple unique IPv6 addresses. In this manner, nodes may be multi-homed.

The M-node may send a Layer 3 SNMP TRAP or INFORM message to a BOS backend system at 406. Alternatively, the DNS server may signal to the BOS via SNMP. Preferably, the SNMP TRAP or INFORM message will include at least one IPv6 address of the M-node (and may include multiple associated network addresses).

16/41 with node Μ). At 4 04 the BOS receives the SNMP TRAP or INFORM message and responds with a Layer 3 message such as a GMI (Generic Management Interface) data query. The GMI data query message may request information about node Μ. For example, if node M is a meter in a utility network, the GMI data query message may request information about the meter configuration parameters, meter status, information about the metered consumable, etc. At 408 node M receives the data query message and sends a data response message. At 409 the BOS receives the data response message from node M.

The BOS can request the network address of a given node at any time. For example, if the BOS has not received a message from node M when a message was expected, the BOS can query node M. If the BOS does not already have the network address of the M-node, or, as in a presently preferred embodiment, if the network is configured to request a network address unless the BOS is responding to a received message, the BOS may perform a query (i.e., a DNS resolution request) with the DNS server. At 410 the BOS sends an IPv6 network address query message from the M-node to the DNS server. At 411 the DNS server responds to the BOS with an IPv6 address for node M for the BOS (if the DNS server has a network address for node M, otherwise the DNS server may respond that it does not have a network address for node M). The IPv6 address for node M is received at 412.

In case the node is not registered, or if the BOS does not

17/41 Upon receiving a network address for the node, the BOS may attempt to programmatically derive the IP address or may attempt to generate an IP address. The BOS may create an adhoc IPv6 address using the AP's IPv6 address and the node's MAC address (as described above). The BOS may also send an IPv6 message to the AP requesting that the AP send a message to the node based on the node's unique MAC identifier. Alternatively, the BOS may request that the AP check the node's connection to determine the node's network address and/or investigate the results of the registration process.

In case node M encounters a problem, for example, a power outage, a security incident, a problem with its hardware or software, a network problem, etc., node M can send a message indicating a problem to the BOS (or to any device that can be reached by node M) such as an SNMP TRAP or INFORM message. In case of a power outage, node M can send a last gasp message. At 413 node M sends a last gasp message to the AP. Typically, the two most recent last gasp messages are very short with only essential information to conserve node and network resources, so that the message is reliably received by other neighboring nodes and the corresponding AP. At 414 the AP receives the last breath message from node M, and in the currently preferred embodiment packages an SNMP TRAP or INFORM PDU (SNMP Packet or Protocol Data Unit) with L2 last breath messages and sends them to the BOS indicating that the AP has received a last breath message from node M.

18/41

Example 2 - Network Addressing for Transport Nodes

This example has a particular node that is a transportation device as shown in Figure 5. Specifically, Node H is a hybrid car that can have its batteries charged from an electrical grid. By plugging Node H into an electrical outlet, Node H attempts to establish communication with an electricity service billing BOS called BOS-HB. In this example, Node H is within the coverage area of ​​LAN-7, a wireless communication network using the IPv6 protocol. Node H sends a Layer 2 Registration Request message to at least one access point within LAN-7. To the API, an access point within LAN-7 responds with its IPv6 prefix, which is 4ea3. Node H uses the prefix received from the API to create a unique IPv6 address. Node H uses the MAC address of a network card in Node H, along with the IPv6 prefix from the API, to create the unique IPv6 address. Node H sends a Layer 3 registration message to a DNS server associated with LAN-7 and receives an acknowledgement from the DNS server. Node H also registers with a second access point on LAN-7, called AP2. API and AP2 are able to communicate with BOS-HB over a communications network. AP2 sends Node-H its IPv6 prefix of 21ff, which Node-H uses to create a second unique IPv6 address associated with AP2. Node-H then sends an SNMP TRAP or INFORM message to BOS-HB indicating that it is on LAN-7. Additionally, the message to BOS-HB includes information to alert BOS-HB that Node-H is currently connected to the power grid and receiving

19/41 power to recharge the batteries of Node H. BOS-HB sends messages to Node H to inquire about the power usage of Node H and also sends messages to check whether Node H is still on the network. Before sending a message to Node Η, BOS-HB queries the network address of Node H with the DNS server. The DNS server, when responding to query requests corresponding to Node H, may determine which of the two unique IP addresses associated with Node H should be provided to the BOS-HB. In this exemplary embodiment, the DNS server's route record includes a unique preference indicator associated with the IPv6 addresses corresponding to Node H. The preference indicator specifies that AP2 is preferred over API, since AP2 has a more secure connection to AP2 than to API. Thus, the DNS server responds to BOS-HB with the network address associated with ΆΡ2. BOS-HB then uses the network address associated with AP2, which then forwards messages to H-Node through AP2. In the event of a failure to deliver a message from the BOSHB to Node H via AP2, the BOS-HB (or another device in the network) can request and receive the next most preferred network address associated with Node H, and resend the failed message using the next most preferred network address to Node H. Since the next most preferred network address for Node H matches the API, the retry of the failed message is forwarded via the API to Node H. In response to the message failing delivery to the network address associated with AP2, the DNS server may change the preference indicators associated with one or more network addresses associated with H-Node, and

20/41 may also change the preference indicators of other nodes according to one or more criteria (e.g., proximity to Node H, dependence on AP2, dependence on Node H, etc.). The request to change the preference indicator in the DDNS record may originate from any of Node H, BOS-HB, AP-1, AP-2.

Node H responds to the request from BOS-HB received from AP2 by sending a packet including the network address of Node H. If the included network address includes the API prefix, the packet can be forwarded through the API to BOS-HB, thereby allowing a network address to determine which access point, among multiple access points, to use when leaving LAN 7. Node H must include this in the header of the packet sent from Node H. By forwarding packets based on the access point prefix included in Node Η, the LAN exit point can be selected, allowing exit control in multiple exit modes.

When the H-Node is a mobile node capable of moving from one location to another (which may result in moving out of direct contact with a given AP, node, or LAN), the AP may deregister a mobile node. For example, mobile nodes may be deregistered if they have not been in communication with the AP for a predefined or configurable period of time. Additionally, or alternatively, mobile nodes may send information to one or more APs not to deregister them, or policies at the AP may decide not to deregister a given mobile node based on one or more characteristics.

21/41

SYSTEM COMPONENTS IN SUPPORT OF IPv6 PUBLIC UTILITY SERVICE NETWORKS

Utility networks capable of supporting communication using IPv6 addressing and protocols may utilize a variety of devices capable of communicating, preferably using IPv6. In the presently preferred embodiment, system components such as a utility node, an access point, and a backend system would have IPv6 functional support integrated into the respective system component. Exemplary preferred embodiments of IPv6-capable system components are shown and described in connection with Figures 6, 7 and 8.

Figure 6 is a generalized block diagram of a node 600 as may be found in the communications network 600 described above. In a preferred embodiment, the node 600 may include a device information controller 601, memory 602, LAN radio interface and controller 603, private radio interface and controller 604, external data interface and meter 605, and IPv6 protocol controller 609. The external meter data interface 605 may connect to a slave device 606, local meter data interface 607, and/or an external sensor device output interface. The IPv6 protocol controller 609 may receive and send IPv6 packets, and may also create or maintain IPv6 tunnels or encapsulate/decapsulate packets as needed.

Although exemplary node 600 does not include a meter for measuring a consumable good, alternative embodiments may include the measurement capability.

22/41

Although exemplary node 600 does not include radios such as a private network radio or LAN radio, alternative embodiments of the node may include one or more radios.

Although exemplary node 600 is described as a single device, alternative embodiments may use multiple computers, electronic devices, or radios in implementing exemplary node 600.

Figure 7 is a generalized block diagram of an access point 700 as might be found in the communications network 600 described above. 0 access point 700, which may also act as a gateway to nodes on a network such as a wireless LAN, may include an access point information controller 701, memory 702, a WAN interface 703, a private wireless radio network controller 704, a wireless LAN radio interface and controller 705, and IPv6 network ID protocol controller 706. The IPv6 network ID protocol controller 706 may also include a tunnel broker, or a tunnel broker may be included separately from the 6-in-4 router and formatter in embodiments utilizing a tunnel broker.

Although exemplary access point 700 does not include radios such as a private network radio, WAN radio, or LAN radio, alternative embodiments of the access point may include one or more radios.

Although the exemplary access point 700 is distinct from a meter or other device on the network (e.g., a relay, etc.) alternative embodiments could combine the functionality of a node, meter, relay, or any other device or system on the network.

23/41

Although access point 700 is described as a single device, alternative embodiments may use multiple computers, electronic devices, or radios in implementing access point 700.

Figure 8 is a generalized block diagram of the backend system 800 as found in the communications network 500 described above. The backend system 800 may include a communications server 801, a wireless private network communications controller 802, a 6-in-4 router and formatter 803, an application server 804, and a database server 805. The wireless private network communications controller 802 may communicate with a private wireless network. 0 The 6-in-4 803 router and formatter may communicate with the WAN. The 6-in-4 router and formatter may also include a tunnel mediator, or a tunnel mediator may be included separately from the 6-in-4 router and formatter in embodiments utilizing a tunnel mediator. The WAN may be the Internet, an intranet, or any other type of wide area network. Alternatively, the formatter may be a 6-to-4 formatter for IPv6 encapsulation. The application server can be any type of application that can be used in a utility network. Examples without limitation include billing applications, accounting applications, power outage detection and/or management applications, configuration and/or provisioning applications, network applications such as a proxy server, a DNS or DNS server, a storage medium, backup and/or recovery application, a user interface application (e.g.

24/41 example, an interface application to allow a user to control aspects associated with a node or to control aspects of a node), a node manager, a content management or delivery system, a communication provisioning application or communication manager, etc.

Although the backend system 800 is described as a singular entity, it may be implemented on one or more computers, for example, on multiple servers in a data center. The described components of the backend system 800 may be implemented on different computers, or may be implemented across multiple computers. Additionally, the backend system 800 may be implemented across multiple computers in multiple locations or on multiple networks. The backend system 800 may also aggregate or include multiple applications. For example, the backend system may include an accounting system as well as a customer billing system. As another example, the backend system may include a billing system and a proxy server. Additional combinations of any number of applications may be included in additional alternative embodiments.

UTILITY SERVICE NODE SUBNETS

Figure 9 is a generalized block diagram utilizing a utility node subnetwork 900. The network 900 may include a utility node 901. The utility node may include a commodity meter, or may interface with a commodity meter.

25/41 utility node 901 is capable of communicating with a communications network 902. In a preferred embodiment, utility node 901 includes a wireless radio capable of communicating with a wireless LAN using IP protocols (IPv4 or IPv6). Utility node 901 also includes an on-premises device interface 903. The on-premises device interface 903 connects to the devices in the on-premises 904 to provide a communication link between the utility node and the devices in the on-premises. Additionally, the utility node may provide a communication link between the devices in the on-premises 904 and the communications network 902 connected to the utility node.

In a currently preferred embodiment, the utility node enclosure device interface 903 assigns a network address to devices in the enclosure that are capable of communicating with it. In one possible embodiment, the network address assigned by the enclosure device interface 903 is an IP address. Preferably, the network address assigned to a device in the enclosure is unique within the communications network 902. The enclosure device interface 903 may also share, or allow sharing, of the network address assigned to an enclosure device outside of the subnet within the enclosure. Thus, devices within the enclosure are directly addressable from outside of the enclosure subnet. The utility node represents the assigned IP address on behalf of the corresponding enclosure device, allowing other nodes in the enclosure to access the IP address assigned to the enclosure device.

26/41 communication network communicate with the device in the enclosure using the assigned IP address. Example 3 illustrates this through one possible embodiment.

Example 3 - On-Premises Communication Using IPv6 Network Addressing

This example is of a utility node with a node name of Node 31 Cedar Ave. Node 31 Cedar Ave is employed in a residential unit (a house) and is capable of communicating with on-premises devices (devices within the house) via multiple communication protocols and technologies. For example, the 31 Cedar Ave utility node can communicate with devices using a wireless personal area network (WPAN) or using PLC (Power Line Carrier) communications with PLC-capable devices connected to the home's power grid. The exemplary home includes five devices in the room, a thermostat communicating over WPAN, a pool pump communicating over WPAN, a freezer communicating over PLC, and a home entertainment system communicating over WPAN.

WPAN can be any one, or any combination, of networking technologies or standards including, without limitation, Bluetooth, ZigBee (IEEE 802.15.4), IrDA, UWB (IEEE 802.15.3), Dust TSMP, Insteon, other IEEE 802.15-based technologies, etc.

The 31 Cedar Ave Utility Node communicates wirelessly with a utility network using IPv6 communication protocols. The utility network includes other utility nodes

41/41

The invention has been described with reference to specific embodiments. However, it will be readily apparent to those skilled in the art that it is possible to embody the invention in specific forms other than the preferred embodiments described above. This may be done without departing from the spirit of the invention.

Accordingly, the preferred embodiment is merely illustrative and should not be considered as restrictive in any way. The scope of the invention is provided by the appended claims 10, rather than by the preceding description, and all variations and equivalents falling within the scope of the claims are to be embraced thereby.

27/41 t

utility services and at least one access point, as well as a BOS to manage Node 31 Cedar Ave.

The 31 Cedar Ave Utility Node includes an electricity usage meter that 5 monitors and reports your home's electrical usage.

Additionally, Node 31 Cedar Ave includes an interface for other consumer goods meters, which is connected to a natural gas meter that monitors and reports the home's natural gas usage.

Node 31 Cedar Ave assigns an IPv6 address to each of these devices in the enclosure. Node 31 Cedar Ave shares the IPv6 address assigned to the thermostat, pool pump, freezer, and entertainment system with the communications network. Specifically, the network addresses of the devices in the premises are shared with a management portal in the premises which is connected to the utility network and which allows the homeowner to monitor and control the devices in the premises. The network addresses of one or more devices in the premises may also be represented by Node 31 Cedar Ave within the communications network or which may communicate via the communications network with Node 31 Cedar Ave.

Through the management portal on the premises, the homeowner (or others) can communicate with the devices on the premises using the assigned IP address. Node 31 Cedar Ave receives packets destined for the devices on the premises, identifies the intended device based on the assigned IP address, and sends the payload of the packets to the intended device.

28/41 through the appropriate on-premises communication system (WPAN, PLC, etc.). Similarly, communication signals from the on-premises device received through the on-premises communication system are introduced into the payload of a packet(s) and sent to the on-premises management portal, including the network address assigned to the on-premises device.

The registry entry in the enclosure for the devices in the enclosure might say:

Registration at the Venue

<td>Device Name in Enclosure</td><td>Address of IPv6 Network Assigned</td><td>Communication Technology in the Venue</td><td>Address Native</td>

<td>Thermostat</td><td>Address 1</td><td>ZigBee</td><td>Zi</td>

<td>Freezer</td><td>Address 2</td><td>PLC</td><td>PLCi</td>

<td>Pool Pump</td><td>Address 3</td><td>ZigBee</td><td>z₂</td>

<td>System of Entertainment</td><td>Address 4</td><td>ZigBee</td><td>z₃</td>

Cedar Ave Node 1 uses assigned network addresses and on-premises communication technology to enable communication between devices on the premises and communication networks outside the premises.

In a preferred embodiment, the utility node may also maintain an access control list (ACL) for devices in the premises. Using the ACL, the utility node allows access to a device in the premises in accordance with the ACL. For example, the ACL may specify that a home security system may only allow access from a security portal. Any device or system attempting to access the premises may be granted access to the premises only through a security portal.

29/41 communicating with the home security system will be denied access unless it provides the appropriate verification information specified in the ACL as corresponding to the security portal.

The utility node ACL can also specify service ports or network daemon names that are permissible for either, or both, incoming and outgoing traffic.

In a currently preferred embodiment, the utility node may assign network addresses that can be forwarded to devices in the enclosure. Devices in the enclosure may not be able to use the network address, as in Example 3 above, where the WPAN and PLC devices use their own network address and are assigned an IP address. Thus, the network address assigned to the device in the enclosure is represented by the utility node. In embodiments using IPv6, an access point may assign a portion of its allocated IPv6 addresses to the utility node. In turn, the utility node may allocate addresses to devices in the premises from the IPv6 addresses assigned to the utility node. In a preferred embodiment, the AP may allocate a block of contiguous addresses to one or more utility nodes. Utility nodes can then assign any of the allocated addresses, or portions thereof, to devices in the enclosure.

The network address assigned to a device may be partially or completely based on the MAC address.

30/41 the utility node communicating with the device, an access point, or the device itself.

Additionally, or alternatively, rules or policies may be used to determine the allocation of addresses to devices in the enclosure. The rules may be based on the type of device, device attributes, network technology or network protocol used by the device, the type of consumable usage of the device (e.g., electricity, gas, water, etc.), the history or characteristic of the consumable usage of the device (e.g., high usage, moderate usage, etc.), the room or section of a room in which the device is physically located, or designated attributes of the device (e.g., the importance of a device, the use of a device such as medical equipment, fire suppression equipment, safety equipment, emergency response equipment, etc.), or in relation to attributes designated by a user of the device or the owner/operator of the premises. Rules may also combine multiple factors listed above, for example, considering the type of device, the physical enclosure, the electrical power consumption, and whether the device is related to emergency response or security.

Additionally or alternatively, some network addresses may be reserved for specific devices, uses, users, etc. For example, certain network addresses may be reserved for emergency personnel or their equipment. Thus, a mobile device in an emergency responder's enclosure that appears at a certain

31/41 subnet in the enclosure may be assigned an address from a pool of addresses reserved for such emergency responder devices. The address provided from the reserved address pool can also be allocated according to a rule, for example, assigning an address based on the type of responder (police, fire department, EMT, etc.), the affiliation or organization thereof (department, police district, etc.), the type of device, or any other attribute of the organization, purpose, and device, etc.

Example 4 illustrates a possible embodiment for implementing address allocation to utility nodes and assigning allocated addresses to devices in the enclosure using utility nodes.

Example 4 - Assigning IPv6 Network Addresses in the Precinct

A utility node with a node name of HM Meter is deployed in a residential unit (a house) and is capable of communicating with on-premises devices (devices within the house or in neighboring houses) via multiple communication protocols and technologies. Additionally, the HM Meter also includes a consumable meter that measures the electricity used in the house. The HM Meter can communicate with devices using WPAN or PLC, with PLC-capable devices connected to the home's power grid. The home includes six devices in the room that can communicate with the HM Meter: a thermostat communicating via WPAN, a freezer communicating via PLC, a home alarm system communicating via

32/41 communicating via WPAN, a video camera which monitors a part of the house and communicates via WPAN, a health monitoring system which can monitor the health conditions of an elderly relative and which communicates via WPAN, and a home entertainment system communicating via WPAN.

The HM Meter communicates wirelessly with the utility network using IPv6 communication protocols. The utility network includes other utility nodes and access points AP214, AP137, and AP8, as well as a BOS for managing the HM Meter. The BOS also includes a customer portal that allows a homeowner to either monitor or control, or both, some or all of the devices in the premises.

AP214, AP137, and AP8 each have a /64 allocation of IPv6 addresses. AP137 has been allocated a /125 allocation of IPv6 addresses to the HM Meter at the utility node. The HM Meter selects addresses from its /125 allocation of IPv6 addresses to assign addresses to the device in the premises that is registered to it. The HM Meter assigns addresses to the thermostat communicating via WPAN, the freezer communicating via PLC, the home alarm system communicating via WPAN, the video camera communicating via WPAN, the health monitoring system communicating via WPAN, and the home entertainment system communicating via WPAN. In the event that one or more devices in the room are removed, or

33/41 unregistered from the HM Meter, then the HM Meter may reassign the network address assigned to the removed or unregistered device in the enclosure to another device in the enclosure.

The allocation of address blocks to utility nodes may be segregated according to various criteria. For example, different sections of the utility network, geographically or logically, may have address blocks allocated from a subset of available address blocks.

While the above exemplary embodiments have devices in the enclosure communicating with a utility node which is assigned to (or installed in) the utility node's enclosure, alternative embodiments may allow devices in the enclosure to communicate through utility nodes from neighboring enclosures.

Although the above example used contiguous blocks of a certain size according to CIDR (Classless Inter-Domain Routing) notation, alternative embodiments could use address blocks of any size, contiguous or non-contiguous. PACKET TRANSIT FROM AN IPv6 NODE THROUGH AN IPv4 NETWORK

The determination of whether 6-to-4 or 6-in-4 communication is used over an IPv4 network can be made by the access point, the backend system, or another system component. Communication between an IPv6 node in the utility network over

34/41 an IPv4 network can be through 6-to-4 communication or 6-in-4 communication, depending on the type of node, the type of network, the selected access point, the backend system, the type of message, the content of the message, the desired level of security, etc. For example, for greater security, 6-in-4 communication can be used. Note that 6-in-4 communication is often referred to as tunneling, while 6-to-4 communication is often referred to as network address translations (NAT) or packet encapsulation.

Figure 10 is a generalized block diagram illustrating a network 1000 where an IPv4 tunnel connects an IPv6 LAN to an IPv6 backend system. Network 1000 includes two local area networks 1001 and 1002. LANs 1001 and 1002 include nodes 1003. In the currently preferred embodiment, nodes 1003 are utility nodes. LAN 1002 is connected to API access point 1004. LAN 1001 is connected to AP2 access points 1005 and AP3 access points 1006. The API access point 1004 and the AP2 access point 1005 connect to the communications network 1007. The AP3 access point 1006 connects to the communications network 1008. In the presently preferred embodiment, the communications networks 1007 and 1008 are wide area networks. The BOS1 backend system 1009 connects to the WAN 1007. The BOS-2 backend system 1010 connects to the WAN 1007 and WAN 1008. The BOS-3 backend system 1011 connects to the WAN 1008.

In the exemplary embodiment, the LANs 1001 and 1002 communicate using the IPv6 protocol. Similarly, the WAN 1008 uses the IPv6 communication protocol. The AP3 access point 1006, connecting the LAN 1001 to the WAN 1008, uses

35/41

IPv6. The BOS-1 1009, BOS-2 1010 and BOS-3 1101 back-end systems all use the IPv6 communication protocol.

WAN 1007 is an IPv4 network, and does not support IPv6. Access points 1004 and 1005 that connect LANs 1002 and 1001, respectively, to WAN 1007 are capable of communicating using IPv6 and participate in a mechanism that facilitates the transit of IPv6 packets through WAN 1007 to BOSs 1009 and 1010, and vice versa.

A message from a node 1003 on LAN 1002, destined for BOS-1 1009 or BOS-2 1010, is sent using an IPv6 address and packet format to API access point 1004. API 1004 creates and uses an IPv6 tunnel (dynamically or manually configured) over WAN 1007. An IPv6 packet from a node 1003 on LAN 1001 to BOS-2 1010 may route the packet over WAN 1007 or over WAN 1008. If the IPv6 packet is to be forwarded through WAN 1008, AP3 1006 is used and when WAN 1008 is an IP6 network, no tunneling, translation or encapsulation needs to be performed. However, if the packet is forwarded through WAN 1007, then AP2 1005 is used and the IPv6 packet from node 1003 will either be passed through a 6-to-4 tunnel as described in Figure 10, or it may be encapsulated in an IPv4 packet for transit through WAN 1007 in a 6-to-4 virtual tunnel as described below in connection with Figure 12.

As shown in Figure 11, the packet flow between the access point associated with the IPv6 LAN and the BOS is through the IPv4 WAN.

Figure 12 is a generalized block diagram

36/41 illustrating a network 1200 where IPv6 packets are passed over an IPv4 WAN. Network 1200 may include two local area networks 1201 and 1202. LANs 1201 and 1202 include nodes 1203. In the presently preferred embodiment, nodes 1203 are utility nodes. LANs 1201 and 1202 communicate with nodes 1203 using IPv6 protocols and addressing. LAN 1202 is connected to API access point 1204. LAN 1201 is connected to AP2 access points 1205 and AP3 access points 1206. The API access point 1204 and the AP2 access point 1205 connect to the communications network 1207. The AP3 access point 1206 connects to the communications network 1208. In the currently preferred embodiment, the communications networks 1207 and 1208 are wide area networks that communicate using IPv4 protocols and addresses. The BOS-1 backend system 1209 connects to the WAN 1207. The BOS-2 backend system 1210 connects to the WAN 1208. The BOS-3 backend system 1211 connects to the WAN 1208.

A node 1203 on LAN 1201 or 1202 sending a message to one or more of the backend systems BOS-1, BOS-2, and BOS-3 must pass through one or more IPv4 WANs 1207 or 1208.

Node 1203 on LAN 1201 or 1202 sends an IPv6 packet using an IPv6 address to the appropriate access point for communication with the intended backend system. In the event that BOS-1 1209 is the intended backend system, API 1204 may be used to connect to WAN 1207. API 1204 receives the IPv6 packet from node 1203, and may encapsulate the received IPv6 packet in the payload portion of an IPv4 packet. The API may have

37/41 or acquire a global IPv4 address for itself for this purpose. The IPv4 header with Protocol 41 is added at the beginning of the IPv6 packet. An IPv4 address associated with BOS-1 is used in the IPv4 packet with the IPv6 packet as payload (the IPv6 packet is a datagram inside the IPv4 packet). The BOS-1 IPv4 address for the prepended packet header may also be derived from the encapsulated packet's IPv6 destination address by extracting the 32 bits after the 2002:: prefix from the IPv6 destination address. In such an embodiment, the IPv4 source address in the prepended packet is the API's IPv4 address. The IPv4 packet is then transmitted to the BOS-1 1209 over the WAN 1207. The BOS-1 1209 receives the IPv4 packet, and extracts the encapsulated IPv6 packet. The IPv6 packet payload is extracted by the BOS-1 1209. In this way, the API 1204 and BOS-1 1209 utilize a 6-to-4 tunnel translation across the IPv4 WAN 12 07 without establishing an explicit tunnel.

Alternatively, API 1204 receives the IPv4 packet from node 1203, and encapsulates the IPv6 packets within UDP packets for transmission to BOS-1 1209 using WAN 1207. As above, in this manner API 1204 and BOS1 1209 are able to exchange IPv6 packets over IPv4 WAN 1207.

The BOS-1 1209 intending to send a message to node 1203 over the IPv4 WAN and IPv6 LAN may send an IPv4 packet to the API 1204 over the WAN 1207. The API 1204 may add an IPv6 prefix to the beginning of the IPv4 address of the packet received from the BOS-1 1209 and destined for node 1203, allowing the IPv4 address to be converted

38/41 effectively for the transmission of the received packet through the IPv6 LAN 1201.

In yet another alternative embodiment, an explicit IPv6 tunnel may be created across one or more IPv4 WANs (or more than one IPv6 tunnel may be created across a given IPv4 WAN) as also discussed above in connection with Figure 10. For example, node 1203 on LAN 1201 or 1202 sends an IPv6 packet using the IPv6 address to the appropriate access point for communication with the intended backend system. In the event that BOS-1 1209 is the intended backend system, API 1204 may be used to connect to WAN 1207. API 1204 receives the IPv6 packet from node 1203, and may establish an IPv6 tunnel (or may access an established IPv6 tunnel) over IPv4 WAN 1207. A tunnel broker (not shown) may establish an IPv6 tunnel over IPv4 WAN 1207. This is a configured tunnel (referred to as a 6-in-4 tunnel) where traffic between nodes on either side of the intended BOS and AP nodes, in the currently preferred embodiment, always uses this tunnel. A configuration script may be exchanged between the utility network access point and a backend system in establishing the tunnel across the WAN. In a preferred embodiment, API 12 04 establishes the IPv6 tunnel to BOS-1 1209. However, alternative embodiments may have one or more backend systems establish a 6-in-4 tunnel across a WAN to one or more access points. The 6-in-4 tunnel is a configured tunnel. In alternative embodiments, UDP encapsulation of IPv6 packets may also be used, for example, to prevent the

39/41 packet in transit through WAN 1204 is blocked by any NAT (Network Address Translation) device that may be present on WAN 1207.

The IPv4 and IPv6 packets received by API 1204 are forwarded to BOS-1 1209 via the 6-in-4 tunnel over WAN 1207. BOS-1 1209 receives and processes the IPv6 packet. Similarly, BOS-1 1209 may forward the IPv6 packets to node 1203 via API 1204 using the 6-in-4 tunnel over WAN 1207. TRANSIT OF IPv4 PACKETS OVER AN IPv6 UTILITY LAN

Figure 13 is a generalized block diagram illustrating a network 1300 where IPv4 packets are passed over an IPv6 LAN. Network 1300 may include two local area networks 1301 and 1302. LANs 1301 and 1302 include nodes 1303. In the currently preferred embodiment, nodes 1303 are utility nodes. LAN 1302 is connected to API access point 1304. LAN 1301 is connected to AP2 access points 1305 and AP3 access points 1306. Access point 1304 and access point 1305 connect to communications network 1307. Access point 1306 connects to communications network 1308. In the currently preferred embodiment, communications networks 1307 and 1308 are wide area networks. BOS-1 backend system 1309 connects to WAN 1307. BOS-2 backend system 1310 connects to WAN 1307 and WAN 1308. BOS-3 backend system 1311 connects to WAN 1308.

Nodes 1312 on LAN 1301 are IPv4 nodes communicating using IPv4, whereas LAN 1301 uses IPv6. Node 1312 sending a message to BOS 1310,

40/41 which connects to LAN 1301 via IPv6 WANs and address points, can be accomplished by node 1312 sending an IPv4 packet on LAN 1301.

Node 1312 sends its IPv4 packet to AP2 for forwarding to BOS-1 1309. In this case, AP2 has the ability to read the destination header in the IPv4 packet, but does not reformat the packet; the packet traverses BOS-1 1309 or BOS-2 1310 over the IPv4 WAN 1307; BOS-1 1309 and BOS2 1310 have the ability to strip the IPv4 packet, read the source information and payload; BOS-1 1309 and BOS-2 1310 also generate IPv4 packets destined for IPv4 node 1312 to traverse the WAN 1307, and forward to node 1312 via AP2 1305.

In a possible alternative embodiment, the AP2 1305 has the ability to map and convert the IPv4 address and headers to IPv6 and also read and map the payload in the IPv6 packet. From there, the IPv6 packet travels through the WAN 1307 in 6-to-4 or 6-in-4 tunnels as all other IPv6 packets do; the BOS 1309 and BOS 1310 receive and process the reformatted IPv6 packet, and also generate an IPv6 packet in any response to, or communication with, node 1312. The return IPv6 packet is converted to IPv4 format by AP2 1305 before being forwarded to node 1312.

In yet another possible embodiment, the IPv4 packet from node 1312 destined for BOS 1310 or BOS 1311 over the IPv6 WAN is converted to IPv6 format by AP2 1305 or AP3 1306, and forwarded to BOS 1310 or BOS 1311 (in this manner, 6-in-4 or 6-to-4 tunneling need not be involved).