|Publication number||US7602747 B2|
|Application number||US 11/193,275|
|Publication date||Oct 13, 2009|
|Filing date||Jul 29, 2005|
|Priority date||Jul 29, 2005|
|Also published as||US20070025292|
|Publication number||11193275, 193275, US 7602747 B2, US 7602747B2, US-B2-7602747, US7602747 B2, US7602747B2|
|Inventors||Tomasz Maksymczuk, Michal Mamczynski|
|Original Assignee||Intel Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (12), Non-Patent Citations (6), Referenced by (23), Classifications (18), Legal Events (6)|
|External Links: USPTO, USPTO Assignment, Espacenet|
Various embodiments described herein relate generally to mobile nodes in a wireless network and more particularly to systems and methods to increase mobility of those mobile nodes.
Wireless devices are a ubiquitous part of every user's daily life. Through either a cell phone, Wireless Fidelity (Wi-Fi) capable laptop, or wireless enabled Personal Digital Assistant (PDA), a user may be wirelessly connected to a wireless network continually. However, the user rarely remains fixed in location. The user continually moves about the network. As the user moves about the network, his or her device may require manual reconfiguration with every network change in the worst case, or the user may experience a momentary loss of connection as the device reconfigures itself in the best case. In the latter situation, if the user is using services requiring high Quality of Service (QoS), the user will experience a less than pleasing user experience.
In the drawings, which are not necessarily drawn to scale, like numerals describe substantially similar components throughout the several views. Like numerals having different letter suffixes represent different instances of substantially similar components. The drawings illustrate generally, by way of example, but not by way of limitation, various embodiments discussed in the present document.
In the following detailed description of embodiments of the invention, reference is made to the accompanying drawings which form a part hereof, and in which are shown, by way of illustration, specific preferred embodiments in which the subject matter may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice them, and it is to be understood that other embodiments may be utilized and that logical, mechanical, and electrical changes may be made without departing from the spirit and scope of the present disclosure. Such embodiments of the inventive subject matter may be referred to, individually and/or collectively, herein by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed.
This application refers herein to certain Request for Comments (RFC) as defined by the Internet Engineering Task Force (IETF) and the Internet Engineering Steering Group (IESG) which are recorded and published as standards track RFCs. Request for Comment 3775 (D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6,” RFC 3775, published June, 2004) specifies a protocol which allows nodes to remain reachable while moving around in the Internet based on Internet Protocol Version 6 (IPv6). Request for Comment 2461 (T. Narten, E. Nordmark, W. Simpson, “Neighbor Discovery for IP Version 6 (IPv6),” RFC 2461, published December 1998) specifies the Neighbor Discovery protocol for IPv6. IPv6 nodes on the same network use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. Request for Comment 2462 (S. Thomson, T. Narten, “IPv6 Stateless Address Autoconfiguration,” RFC 2462, published December 1998) specifies the steps a host takes in deciding how to autoconfigure its interfaces in IPv6.
Reference is also made herein to the proposed specification for Hierarchical Mobile IPv6 (HMIPv6). HMIPv6 is being finalized by the Mobile IPv6 Signaling and Handoff Optimization (mipshop) working group of the IETF and deals with reducing the amount and latency of signaling amongst a mobile node, its home agent and one or more correspondents by introducing a mobility anchor point (e.g., a special node located in the network visited by the mobile node). In the proposed specification, the mobility anchor point acts somewhat like a local home agent for the visiting mobile node by limiting the amount of signaling required outside the mobility anchor point's domain. The HMIPv6 proposed specification is currently an Internet Draft and has not yet been advanced to the standards track and RFC status. The current version of the HMIPv6 Internet-Draft, published December 2004, and which expires in June 2005, can be found at http://www.ietf.org/internet-drafts/draft-ietf-mipshop-hmipv6-04.txt. As explained in the Guidelines to Authors of Internet-Drafts, available at http://www.ietf.org/ietf/1id-guideliries.html, last updated on Mar. 25, 2005, Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. References herein to the HMIPv6 Internet-Draft are made therefore for informational purposes since it is understood that the HMIPv6 Internet-Draft is a work in progress.
“Data items” as used in the present discussion may include, without limitation: wireless data signals, network packet data, network signals, etc. Wireless data signals may include, without limitation, signals in accordance with one or more of the following standards: Global System for Mobile Communications (GSM); General Packet Radio Service (GPRS); Code Division Multiple Access (CDMA); Time Division Multiple Access (TDMA); IEEE 802.11 standard signals, IEEE std. 802.11-1999, published 1999 and later versions (hereinafter IEEE 802.11 standard); IEEE 802.16 standard signals, IEEE std. 802.16-2001, published 2001 and later versions (hereinafter IEEE 802.16 standard); IEEE 802.15 standard signals, IEEE std. 802.15.1-2003, published 2003, IEEE 802.15.2-2003, published 2003, IEEE 802.15.3-2003, published 2003 and later versions (hereinafter IEEE 802.15 standard); Wide Band CDMA (WCDMA); High Speed Downlink Packet Access (HSDPA); or Ultra WideBand (UWB). Though specific types of wireless signals are listed above, for the embodiments herein it is to be appreciated that any signal that passes between two devices without a wire is considered to be a wireless signal. Though mention is made here to wireless signals, the systems and methods described herein apply equally to wired as well as wireless networks in the context of router to router communications.
The term “router” as used herein is meant to denote any device on a network configured to receive data items addressed to other devices on the network and forward those data items to the appropriate device using any suitable communications protocol.
In an embodiment, the MAP 102 is a device located in the network 100 accessible by one or more MNs 108. Accessible, includes, without limitation the ability of a MN 108 to communicatively connect to and begin transmitting data items to and receiving data items from ARs 106 on the network 100, and through the ARs 106 and other devices on the network, the MN 108 is capable of transmitting and receiving data items to and from the MAP 102. In an embodiment, the MAP 102 is used by the one or more MNs 108 as a local home agent (HA). The MAP 102 as a local HA for the one or more MNs 108 allows seamless connectivity for the one or more MNs 108 as the MNs 108 move around in the network 100. Though depicted as a single device in
In an embodiment, the ARs 106 are devices on the network accessible to one or more MNs 108. In an embodiment, each of the ARs 106 is configured to be a default router for one or more MNs 108. Each of the ARs 106 is further configured to aggregate the outbound traffic or data items from the one or more MNs 108 to the network 100.
In an embodiment, the MNs 108 are devices, such as, without limitation, computers, mobile phones, or PDA's, configured to communicate wirelessly with at least one AR 106 using MIPv6 as the network protocol. MIPv6 as described in RFC 3775 and HMIPv6 as described in the proposed specification provide a network structure in which a MN 108 can move about the network 100 and still maintain a network connection. As the MN 108 moves from a communicative connection with a first AR 106 to a second AR 106, the network 100 is configured to handoff communications from the first AR 106 to the second AR 106. Through this operation, most data items addressed to and coming from the MN 108 are delivered to their intended recipient.
In an embodiment, the OR 104 is a device configured to receive data items from the MAP 102 that are addressed to a MN 108. In a further embodiment, the OR 104 is further configured to read a hop-by-hop extension option in the header of the data item and forward the data item based on that option. In one embodiment, the OR 104 is a separate device. In another embodiment, the functionality of the OR 104 may be contained either in an AR 106 or the MAP 102. Such an arrangement may be advantageous and allow the network 100 to maintain operations if one or more, but not all, devices on the network 100 fail.
In an embodiment, a MN 108 communicating with an AR 106 is assigned to a dedicated subnet specific to that AR 106. All network traffic received by the MAP 102 addressed to the RCoA of the MN 108 is re-addressed with the subnet prefix of the AR 106 with which the MN 108 is communicating. In one embodiment, the subnet prefix changes as network operations are handed off from one AR 106 to another AR 106. In such an arrangement, any additional network traffic received by the MAP 102 addressed to the RCoA of the MN 108 is re-addressed to the new subnet prefix.
A MN 108 can experience similar radio propagation conditions from more than one AR 106. In the context of the above discussion, the MN 108 maintains communications with only one of the ARs 106. Only when the MN 108 moves or the AR 106 it is communicating with ceases to send and receive network traffic, does the MN 108 hand off network operations to the other AR 106. This creates a hand-off period during which important data can be lost.
In an embodiment, the MN 108 is configured to send measurement reports to the AR 106 when first associating with the AR 106. The MN 108 is further configured to send a measurement report when any change in the quality of the link between the MN 108 and any AR 106 that the MN 108 can communicate with is detected. If the MN 108 is communicating with more than one AR 106, the measurement report is sent to only one AR 106. In an embodiment, the measurement report is a report detailing the radio link quality between the MN 108 and an AR 106. In a further embodiment, the measurement report contains, without limitation, a set of tuples, comprising: access network identity, and signal quality/strength. In one embodiment, the measurement report is sent to the AR 106 using underlying Layer 2 mechanisms as outlined in the Open System Interconnection (OSI) Network Model. In another embodiment, the measurement report is sent using a Router Solicitation message as defined by RFC2461. As provided for in RFC 2461, Router Solicitation messages are messages that request routers to generate a response immediately. In such an arrangement, the measurement report also comprises information additional to the standard Router Solicitation message as described in RFC 2461.
In an embodiment, ARs 106 are configured to receive the measurement report from a MN 108 and prepare an advertisement message based on the received measurement report. In an embodiment, the advertisement message is a message from the AR 106 to the MN 108 providing information regarding network access, including, but not limited to, subnet prefix assignments. The AR 106 maintains a local database and is configured to compare the received measurement report with data in the local database. In an embodiment, the records in the local database may contain, without limitation, information regarding: access network identity; signal quality threshold with respect to the link between a MN 108 and an AR 106; and associated IPv6 subnets. In a further embodiment, overlap subnets may be advertised. Overlap subnets are a subset of regular IPv6 subnets. In an embodiment, and IPv6 subnet is an overlap subnet if there exists another (or many other) subnet(s) that can be used to communicate with the MN 108 with similar link quality. In an embodiment, the association between overlap subnets is maintained in the OR 104.
The MN 108 is capable of auto-configuring its IPv6 address as outlined in RFC 2462. In an embodiment, the MN 108 is further configured to autoconfigure new IP addresses belonging to all assigned overlap subnet prefixes when an advertisement message is received containing overlap subnet prefixes. The MN 108 is configured to use the same interface identifier on all overlap subnets. In a further embodiment, the MN 108 is further configured to send a Local Binding Update (LBU) to the MAP 102 to register the new RCoA which is the auto-configured IPv6 address from the one or more overlap subnets. In such an arrangement, the MAP 102 is further configured to tunnel packets to the RCoA registered by the MN 108. In an embodiment, the MAP 102 is configured to construct a packet with an outer packet header followed by a hop-by-hop extension option and initiate the hop-by-hop extension option to zero. In a further embodiment the hop-by-hop extension header may carry a Multihoming in Overlap Subnets for IP Micro-mobility Robustness (MUHOMOR) hop-by-hop option.
In an embodiment, when a MN 108 is able to communicate with two or more ARs 106, all of the ARs 106 are configured to include subnet prefix information for each of the two or more ARs 106 in any advertisement message sent to the MN 108. In such an arrangement, using
In an embodiment, the MUHOMOR module 210 is configured to receive data items addressed to a MN 108, read a configurable option in the data item and process the data item based on the configurable option in the data item. In an embodiment, the configurable option is a MUHOMOR option. In one embodiment, the MUHOMOR module 210 n-casts the data item to the MN 108 if the MUHOMOR option is set to a non-zero value. In such an arrangement, the MN 108 is configured to multihome on several subnets concurrently and receive n-cast data items sent from the OR 104. “Multihoming” as used herein is a MN's 108 ability to have multiple network addresses in one computer, usually on different networks. In an embodiment, the MAP 102 is configured to insert the configurable option in each data item received by the MAP 102 addressed to the RCoA of a MN 108. In another embodiment, the MAP initializes the configurable option to zero when inserting the configurable option.
At block 310, the device receives a report from one or more mobile nodes, such as the MN 108 depicted in
At block 315, the device compares data in the received report with data stored in a local database. Records in the local database can include, without limitation, access network identity, signal quality threshold and associated IPv6 subnets. In an embodiment, the device compares the link quality reported by the MN 108 with at least one AR 106, and the signal quality threshold contained in the record for the at least one AR 106. In another embodiment, the device compares the link quality reported by the MN 108 with the signal quality threshold for each of the ARs 106. In such an example, if the link quality exceeds the signal quality threshold of any of the ARs 106, the MN 108 has a good link with each of those ARs 106.
In another embodiment, the device compares some other value contained in the measurement report and compares that value with similar data stored in the local database to determine if the some other value exceeds a threshold value for that type of measurement. If it is determined that it does, the MN 108 is determined to have a good link. In such an example, the device determines if the MN 108 has a good link with any of the ARs 106 based on that comparison. In an embodiment, the device assigns one or more subnet prefixes from a group of subnet prefixes associated with each of the ARs 106 that the MN 108 has a good link with. In such an arrangement, the device assigns the one or more subnet prefixes to the MN. If the MN 108 has a good link with only one AR 106, a single subnet prefix is chosen. If the MN 108 has a good link with more than one AR 106, more than one subnet prefix is chosen. In an embodiment, when more than one subnet prefix is assigned to a MN 108, the MN 108 is configured to receive data items addressed to each of the subnet prefixes.
At block 320, the device generates an advertisement message based on the comparison. In an embodiment, the advertisement message contains the assigned subnet prefix as discussed above. At block 325 the device sends the advertisement message to the MN 108 from which it received the report. In an embodiment, if the MN 108 has a good link with only one AR 106, the advertisement message contains one subnet prefix. The MN 108 receives the advertisement message and broadcasts a LBU message to the MAP 102 with that subnet prefix and the RCoA of the MN 108. Further network traffic addressed to the RCoA of the MN 108 is re-addressed to this subnet prefix and forwarded using standard IPv6 forwarding methods.
In an embodiment, if the MN 108 has a good link with more than one AR 106, the device receiving the measurement report generates an advertisement message containing the subnet prefixes of all ARs 106 with which the MN 108 has a good link. The subnet prefixes described here are subnet prefixes assigned to the MNs 108 that are experiencing similar link quality conditions with two or more ARs 106 such that network traffic addressed to the RCoA of the MNs 108 can be handled differently than network traffic addressed to a MN 108 communicating with only a single AR 106. The MN 108 receives this advertisement message and auto-configures new IPv6 addresses belonging to all assigned subnets. The MN 108 sends an LBU message to the MAP 102 and all network traffic addressed to the RCoA of the MN 108 is re-addressed to the assigned subnets.
With reference to
At block 320, data items addressed to mobile nodes assigned to more than one subnet are n-cast to all subnets assigned to the mobile node. With reference to the discussion above in regards to the MN3 108 c, data items addressed to the RCoA of the MN3 108 c is n-cast to the two subnets assigned to the MN3 108 c. As will be understood by those skilled in the art, this is the simple case. In other embodiments, a MN 108 may experience similar radio propagation conditions or a good link from more than two access routers. In such an arrangement, the data items addressed to the RCoA of the MN 108 are n-cast to all subnet prefixes assigned to the MN 108.
At block 410 the device receives data items addressed to a MN 108. At block 415, the device determines if the MN 108 is in an overlap subnet. If the MN 108 is not in an overlap subnet, the data item is forwarded to the MN 108 using standard forwarding at block 420. Standard forwarding includes, without limitation, IPv6 forwarding. If the MN 108 is in an overlap subnet, operations continue at block 425.
At block 425, the device reads a configurable option in the header of the data item. In an embodiment, the configurable option in the header of the data item includes a hop-by-hop extension header. In one embodiment, the configurable option includes a MUHOMOR hop-by-hop extension header. If the configurable option is set to a non-zero value, the data item is forwarded using standard IPv6 forwarding at block 420. If the configurable option is set to a zero value, the device sets the configurable option to a non-zero value at block 430. In an embodiment, the configurable option is set to the value of a global counter maintained by the device. In a further embodiment, the global counter is incremented. In such an arrangement, the global counter must skip zero when the counter flips to zero.
At block 435, the data item is replicated n-times and each of the replicated data items is forwarded to each of the subnet prefixes assigned to the MN 108 to which the data item is addressed. In a case where the MN 108 is assigned two subnet prefixes, the data item is duplicated. In an embodiment, a non-zero value in the MUHOMOR hop-by-hop extension header allows for redundancy among overlap routers in that an overlap router downstream of the first overlap router is still configured to perform the operations outlined here, but only when the upstream overlap router fails will the downstream overlap router n-cast the received data items.
In an embodiment, each device in the network 100 depicted in
The MAP 102 is configured to receive the first network packet 502 and tunnel the packet 502 to the RCoA of the MN 504, wrapping an outer IPv6 header followed by the hop-by-hop extension header carrying the MUHOMOR hop-by-hop option as outlined above around the received first network packet 502. The option would carry a counter that the MAP 102 would initiate to 0, as shown in the second network packet 506.
The second network packet 506 is received by an OR 104 and the MUHOMOR option is read. In this case, the received packet 506 contains a zero value in the MUHOMOR option of the packet header as initiated by the MAP 102 and the MN 504 has a good link with both the AR1 106 a and the AR2 106 b. As discussed above, a determination as to which access router that a mobile node has a good link with is performed by comparing any data indicative of link quality in a measurement report received from a mobile node with similar data indicative of link quality contained in a local database accessible to the access router Examples of such data indicative of link quality include, without limitation, signal to noise ratio, signal strength, noise level, number of devices communicating with the access router, and the like. A good link is an indication that the mobile node is experiencing an acceptable communicative connection with the access router and data items can be transmitted from the access router to the mobile node with a high probability of successful delivery.
As discussed above with respect to
Between OR1 104 a and AR1 106 a, there is an additional overlap router, the OR2 104 b. The OR2 104 b receives the network packet in the same manner as the OR1 104 a. In the example of
For packets addressed to the B2 overlap subnet prefix of the AR2 106 b, the AR2 106 b receives the network packet 510 addressed to the B2 subnet prefix and forward that network packet 516 to the MN 504.
The MN 504 in this example receives duplicate packets containing the same data. The MN 504 is configured to multihome on both the A2 subnet and the B2 subnet concurrently. Any method suitable to provide for multihoming on a mobile node can be used as are well known in the art, and are considered to be within the scope of the present discussion.
Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments of the invention. Combinations of the above embodiments and other embodiments not specifically described herein will be apparent to those of skill in the art upon reviewing the above description.
The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b), requiring an abstract that allows the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Additionally, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments of the invention require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate preferred embodiment. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the terms “comprising” and “wherein,” respectively. Moreover, the terms “first,” “second,” and “third,” etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6487406 *||Apr 10, 2000||Nov 26, 2002||Telcordia Technologies, Inc.||PCS-to-mobile IP internetworking|
|US7082114 *||Dec 28, 2000||Jul 25, 2006||Nortel Networks Limited||System and method for a wireless unit acquiring a new internet protocol address when roaming between two subnets|
|US20010052025 *||Jun 8, 2001||Dec 13, 2001||Nec Corporation||Router setting method and router setting apparatus|
|US20020188723 *||Oct 12, 2001||Dec 12, 2002||Koninklijke Philips Electronics N.V.||Dynamic frequency selection scheme for IEEE 802.11 WLANs|
|US20030110290 *||Dec 6, 2002||Jun 12, 2003||Ntt Docomo, Inc.||Mobile tracking system for QoS guaranteed paths, router device used for this system, mobile communications terminal, and control program for controlling router device|
|US20030112778 *||Dec 19, 2001||Jun 19, 2003||Lundby Stein A.||Efficient multi-cast broadcasting for packet data systems|
|US20040047323 *||Apr 28, 2003||Mar 11, 2004||Sk Telecom Co., Ltd.||Method for selecting system and transmitting data for WLAN and mobile phone network interworking service|
|US20050169202 *||Feb 3, 2004||Aug 4, 2005||Rapeepat Ratasuk||Method and apparatus for dynamic power allocation to a multimedia broadcast/multicast service|
|US20050271020 *||Jun 4, 2004||Dec 8, 2005||Thermond Jeffrey L||Cellular network/WLAN VoIP service interaction by home wireless router|
|US20060020547 *||Nov 3, 2003||Jan 26, 2006||Matti Lipsanen||Hybrid networks|
|US20060166665 *||Apr 26, 2004||Jul 27, 2006||Matsushita Electric Industrial Co., Ltd.||Radio communication system|
|US20060268918 *||May 31, 2005||Nov 30, 2006||Telcom Ventures, L.L.C.||Digital data broadcasting systems, methods and components that selectively rebroadcast data packets based on analysis of propagation characteristics|
|1||El Malki, K., "Simultaneous Bindings for Mobile IPv6 Fast Handovers Networking Working Group, Internet-Draft, (Oct. 2003), 17 pgs.|
|2||Johnson, D., et al., "Mobility Support in IPv6", Networking Working Group, Request for Comments: 3775, (Jun. 2004), 157 pgs.|
|3||Koodli, R. , et al., "Fast Handovers for Mobile IPv6, draft-ietf-mipshop-fast-mipv6-01.tx", Mobile IP Working Group, Internet Draft, (Jan. 30, 2004), 39 pgs.|
|4||Narten, T., "Neighbor Discovery for IP Version 6 (IPv6)", Network Working Group, Request for Comments: 2461, (Dec. 1998), 89 pgs.|
|5||Soliman, H., et al., "Hierarchical Mobile IPv6 Mobility Management (HMIPv6) -ietf-mipshop-hmipv6-02.txt>", Network Working Group, Internet-Draft, (Jun. 15, 2004), 29 pgs.|
|6||Thomson, S., et al., "IPv6 Stateless Address Autoconfiguration", Network Working Group, Request for Comments: 2462, (Dec. 1998), 24 pgs.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7788405 *||Aug 31, 2010||Samsung Electronics Co., Ltd.||Method for automatic configuration of prefixes at maps in HMIPv6|
|US8144596||Nov 21, 2008||Mar 27, 2012||Trilliant Networks, Inc.||Communication and message route optimization and messaging in a mesh network|
|US8171364||Nov 21, 2008||May 1, 2012||Trilliant Networks, Inc.||System and method for power outage and restoration notification in an advanced metering infrastructure network|
|US8289182||Nov 21, 2008||Oct 16, 2012||Trilliant Networks, Inc.||Methods and systems for virtual energy management display|
|US8319658||Mar 11, 2010||Nov 27, 2012||Trilliant Networks, Inc.||Process, device and system for mapping transformers to meters and locating non-technical line losses|
|US8334787||Oct 27, 2008||Dec 18, 2012||Trilliant Networks, Inc.||Gas meter having ultra-sensitive magnetic material retrofitted onto meter dial and method for performing meter retrofit|
|US8370697||Mar 16, 2012||Feb 5, 2013||Trilliant Networks, Inc.||System and method for power outage and restoration notification in an advanced metering infrastructure network|
|US8503416 *||Dec 15, 2010||Aug 6, 2013||Telefonaktiebolaget L M Ericsson (Publ)||Method and system for efficient homeless MPLS micro-mobility|
|US8699377||Sep 4, 2009||Apr 15, 2014||Trilliant Networks, Inc.||System and method for implementing mesh network communications using a mesh network protocol|
|US8725274||Nov 8, 2012||May 13, 2014||Trilliant Networks, Inc.||Energy use control system and method|
|US8832428||Nov 15, 2011||Sep 9, 2014||Trilliant Holdings Inc.||System and method for securely communicating across multiple networks using a single radio|
|US8856323||Feb 9, 2012||Oct 7, 2014||Trilliant Holdings, Inc.||Device and method for facilitating secure communications over a cellular network|
|US8942193||Apr 8, 2011||Jan 27, 2015||Blackberry Limited||Routing different subsets of an internet protocol flow over different points of attachment|
|US8970394||Jan 24, 2012||Mar 3, 2015||Trilliant Holdings Inc.||Aggregated real-time power outages/restoration reporting (RTPOR) in a secure mesh network|
|US9001787||Sep 19, 2012||Apr 7, 2015||Trilliant Networks Inc.||System and method for implementing handover of a hybrid communications module|
|US9013173||Sep 13, 2011||Apr 21, 2015||Trilliant Networks, Inc.||Process for detecting energy theft|
|US9041349||Mar 7, 2012||May 26, 2015||Trilliant Networks, Inc.||System and method for managing load distribution across a power grid|
|US9084120||Aug 26, 2011||Jul 14, 2015||Trilliant Networks Inc.||System and method for interference free operation of co-located transceivers|
|US9189822||Oct 19, 2012||Nov 17, 2015||Trilliant Networks, Inc.||Process, device and system for mapping transformers to meters and locating non-technical line losses|
|US20070088708 *||Sep 29, 2006||Apr 19, 2007||Samsung Electronics Co., Ltd.||Method for automatic configuration of prefixes at maps in HMIPV6|
|US20080123665 *||Nov 28, 2006||May 29, 2008||Honeywell International Inc.||Uwb sensor array network structure|
|US20120155442 *||Dec 15, 2010||Jun 21, 2012||Telefonaktiebolaget L M Ericsson (Publ)||Method and System for Efficient Homeless MPLS Micro-Mobility|
|WO2013106015A1 *||Apr 4, 2012||Jul 18, 2013||Research In Motion Limited||Routing different subsets of an internet protocol flow over different points of attachment|
|U.S. Classification||370/331, 370/401, 455/432.1, 455/436|
|International Classification||H04W40/12, H04W4/00, H04W76/04, H04W84/00|
|Cooperative Classification||H04W84/12, H04W88/005, H04W40/12, H04W8/087, H04W24/10, H04W76/04, H04W84/00, H04W8/085, H04W8/26|
|Jul 29, 2005||AS||Assignment|
Owner name: INTEL CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MAKSYMCZUK, TOMASZ;MAMCZYNSKI, MICHAL;REEL/FRAME:016834/0227;SIGNING DATES FROM 20050722 TO 20050725
|Jan 5, 2010||CC||Certificate of correction|
|Oct 5, 2010||CC||Certificate of correction|
|May 24, 2013||REMI||Maintenance fee reminder mailed|
|Oct 13, 2013||LAPS||Lapse for failure to pay maintenance fees|
|Dec 3, 2013||FP||Expired due to failure to pay maintenance fee|
Effective date: 20131013