Remote fault tolerance for managing alternative networks for high quality of service communications

Abstract
Methods and systems are provided. Exemplary methods may include: providing a first data packet to a first interface, the first data packet including a first address and being received from a computing device, the computing device being at a premises and coupled to a third interface, the first interface coupled to a first broadband connection received at the premises, the first broadband connection being coupled to a service using a first data network; determining at least one second data packet to be received at the first interface from the service is lost or delayed; supplying a second address to the computing device for communications with the service, in response to the determining; receiving from the computing device a third data packet including the second address; modifying the third data packet including replacing the second address with the first address; and giving the modified third data packet to a second interface.
Description
FIELD OF THE INVENTION

The present technology pertains to data networks, and more specifically to high quality of service communications.


BACKGROUND ART

Data bandwidth provided by a hardwired broadband internet connection to a home or small office is finite and divided among competing applications and computing devices. While Internet traffic is handled on a “best effort” basis, current multimedia traffic (e.g., video, voice, and the like) cannot tolerate increasing lost or delayed data before the user experience is degraded. Some home and small office routers can be configured to assign a priority to each device and/or service operating on the home or small office network and control the amount of bandwidth each is allowed to consume. In this way, the computer network performance (perceived by the user), referred to as quality of service (QoS), is managed. If the data loss or data delay occurs outside of the home or small office network (e.g., in an Internet service provider's (ISP's) network, an upstream ISP's network, and the like), then conventionally managing QoS at the home and small office router as described above has limited effect.


SUMMARY OF THE INVENTION

Some embodiments of the present technology include systems for managing alternative networks. The system may include: a first interface coupled to a first broadband connection received at a premises, the first broadband connection being coupled to a service outside the premises using a first data network; a second interface coupled to a second broadband connection received at the premises, the second broadband connection being coupled to the service outside the premises using a second data network and being different from the first broadband connection; a third interface coupled to a computing device at the premises; a processor coupled to the first, second, and third interfaces; and a memory coupled to the processor, the memory storing instructions executable by the processor to perform a method comprising: providing a first data packet to the first interface, the first data packet including a first address and being received from the computing device; determining at least one second data packet to be received at the first interface from the service is lost or delayed; supplying a second address to the computing device for communications with the service, in response to the determining; receiving from the computing device a third data packet including the second address; modifying the third data packet including replacing the second address with the first address; and giving the modified third data packet to the second interface.


According to various embodiments of the present technology include methods for managing alternative networks. The methods may comprise: providing a first data packet to a first interface, the first data packet including a first address and being received from a computing device, the computing device being at a premises and coupled to a third interface, the first interface coupled to a first broadband connection received at the premises, the first broadband connection being coupled to a service outside the premises using a first data network; determining at least one second data packet to be received at the first interface from the service is lost or delayed; supplying a second address to the computing device for communications with the service, in response to the determining; receiving from the computing device a third data packet including the second address; modifying the third data packet including replacing the second address with the first address; and giving the modified third data packet to a second interface, the second interface coupled to a second broadband connection received at the premises, the second broadband connection being coupled to the service outside the premises using a second data network and being different from the first broadband connection.





BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, where like reference numerals refer to identical or functionally similar elements throughout the separate views, together with the detailed description below, are incorporated in and form part of the specification, and serve to further illustrate embodiments of concepts that include the claimed disclosure, and explain various principles and advantages of those embodiments. The methods and systems disclosed herein have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present disclosure so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.



FIG. 1 is a simplified block diagram of a communications system, according to some embodiments.



FIG. 2 is a simplified block diagram of a communications system, in accordance with various embodiments.



FIG. 3 illustrates a scoreboard, according to some embodiments.



FIG. 4 is a simplified block diagram illustrating data flow, in accordance with various embodiments.



FIG. 5 is a simplified flow diagram of a method for routing and readdressing packets, according to various embodiments.



FIG. 6 is a simplified flow diagram of a method for determining whether to use a primary or secondary network, in accordance with some embodiments.



FIG. 7 is a simplified block diagram of a computing system, according to various embodiments.





DETAILED DESCRIPTION

While this technology is susceptible of embodiment in many different forms, there is shown in the drawings and will herein be described in detail several specific embodiments with the understanding that the present disclosure is to be considered as an exemplification of the principles of the technology and is not intended to limit the technology to the embodiments illustrated. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the technology. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and/or “including,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that like or analogous elements and/or components, referred to herein, may be identified throughout the drawings with like reference characters. It will be further understood that several of the figures are merely schematic representations of the present technology. As such, some of the components may have been distorted from their actual scale for pictorial clarity.


Some data networks use a packet-switched approach to transport information between locations. A packet-switched approach breaks up the information into a number of discrete segments, each segment called a packet (also referred to as a datagram, segment, frame, cell, protocol data unit (PDU), and service data unit (SDU). (Numeric) Addresses, such as an Internet Protocol address (IP address), identify each machine (e.g., physical and/or virtual host) and packets are routed from one machine to another over the network using these addresses. Assuming they arrive properly, the packets are re-assembled by the receiving party to reassemble the original information. An alternative to a packet-switched approach is to dedicate a fixed link between sender and receiver for the duration of the time they desire to communicate, an approach known as circuit switching. Packet switching is generally preferred for a number of reasons. One reason is that this is a versatile technique to allow for multiple streams of data to be interleaved or multiplexed on a single physical connection. Another is that portions of the message may be sent over different paths to improve performance or avoid network failures.


Unfortunately, for a variety of reasons packets may be lost when transmitted between the sender and the receiver. Various intermediary devices (e.g., routers, switches, gateways, etc.) that route the packets over available paths between two addresses may become overloaded/congested. Additionally, links between devices may fail, interference may corrupt packets that then must be discarded, resent, etc. For that reason, packet based networks, and the applications built on top of them can use a number of approaches to deal with packet loss. By way of non-limiting example, a “reliable” transport mechanism, such as that provided by Transmission Control Protocol (TCP), is used. TCP is described further in “TCP Congestion Control”, IETF RFC 5681, M. Allman et al., 2009, Internet Engineering Taskforce, which is hereby incorporated by reference in its entirety for any purpose. TCP (and the like) use various techniques to determine if packets have arrived at the destination in a certain time (e.g., several seconds), and if not, to retransmit those lost packets. Note: this is an advantage of packet switched networks, as only the missing packets need be retransmitted.


TCP (and the like) mechanisms can be effective in a bad (e.g., congested and/or lossy) network, but their utility diminishes in a time-sensitive or real-time application. For example, some real-time applications can tolerate the loss of a few packets, which is preferable to receiving a delayed packet. As an example, the loss of half a second of audio during a radio transmission or a phone call is little more than an annoyance, but receiving and replaying that half-second of audio ten seconds later would be very disruptive. Such applications are called “loss-tolerant applications,” and include streaming audio and video, and audio and video communications. Instead of retransmitting, loss-tolerant applications attempt to reduce the incidence/rate and impact of lost packets.


As a result, while some loss is acceptable, different methods are used to reduce lost packet rates for real-time streams. For example, redundant information is used. In this approach, additional, redundant information is used to encode the real-time information and is transmitted along with the original copy. While packets may still be lost, the redundant information can be used to reconstruct the information including lost information, provided too many are not lost. Higher levels of redundancy increase reliability but also increase bandwidth used. For example, Real-time Transport Protocol (RTP), an Internet standard to encapsulate and transport real-time media (e.g., audio, video, etc.) provides an extension to allow marking and transmitting of redundant data alongside the original data. RTP is described further in “RTP: A Transport Protocol for Real-Time Applications”, IETF RFC 3550, H. Schulzrinne et al., 2003, Internet Engineering Taskforce and “RTP Payload for Redundant Audio Data”, IETF RFC 2198, C. Perkins et al., 1997, Internet Engineering Taskforce, which are each incorporated by reference in their entirety for any purpose.


Another technique is to reduce the loss of packets by reducing the quality of the transmission. Lower quality streams require less data to represent, and results in less traffic on the network, in many cases reducing packet loss. A slightly lower quality, but more complete stream, may be preferable, for example during in a phone conversation.


Despite the above techniques, at times the quality of a network connection degrades so much that these techniques are insufficient to produce an acceptable user experience, referred to as Quality of Service (QoS). The network connection simply becomes too degraded to support the real-time stream. QoS is the overall performance of a telephony or computer network, particularly the performance seen/experienced by the users of the network.


As described above, packets can be routed by using network addresses. These addresses uniquely (at least within one organization or location, discussed below) identify various hosts on the network and allow information to be sent from one host to another. Addresses can be numeric (binary) identifiers, by way of non-limiting example, 32-bit Internet Protocol version 4 (IPv4) addresses (e.g., represented as dotted decimal format for human use, such as 192.168.1.1) and the longer 128 bit Internet Protocol version 6 (IPv6) format (e.g., represented as 32 hexadecimal values for human use). IPv4 addresses are identified by four numbers from 0-255 (e.g., 0.0.0.0 to 255.255.255.255), resulting in 232 possible addresses in the address space (although some can be reserved for various purposes). The IPv6 has the advantage of a larger address space than IPv4, which allows more devices to be identified.


Establishing and controlling real-time streams may be logically composed of several functions. In one function, the two parties needing to communicate exchange information to negotiate or initiate the connection and control it. This requires, minimally, the exchange of locations where each party should send information (e.g., IP address and port), allowing the other party to receive it. This may include sending instructions to play, pause, rewind, or fast-forward for pre-recorded media; or to initiate, end, transfer, place on hold, or change properties exchange (switch from audio to video, for example) for an interactive session.


Protocols which may be used to control interactive sessions include: the Internet Engineering Task Force's (IETF) Session Initiation Protocol (SIP); the IETF Extensible Messaging and Presence Protocol (XMPP); and the International Telecommunication Union's (ITU) H.323 protocol, as well as the emerging IETF/World Wide Web Consortium (W3C) work on RTCWeb and WebRTC (which describe how to negotiate such sessions between web browsers). For (pre-)recorded content, the IETF Real Time Streaming Protocol (RTSP) may be used. Other protocols and proprietary mechanisms may also be used. Several protocols also take advantage of the IETF's Session Description Protocol (SDP), encapsulating SDP to describe the actual format (encoding) of the media being exchanged. The above protocols are described further in “SIP: Session Initiation Protocol”, IETF RFC 3261, J. Rosenberg et al., June 2002, Internet Engineering Taskforce; “Extensible Messaging and Presence Protocol (XMPP): Core”, IETF RFC 6120, P. Saint-Andre, March 2011, Internet Engineering Taskforce; Defined by multiple ITU documents, see Wikipedia entry, http://en.wikipedia.org/wiki/H.323; RTCWEB Working group, works in progress, Internet Engineering Taskforce; “Real Time Streaming Protocol (RTSP)”, IETF RFC 2326, H. Schulzrinne et al., 1998, Internet Engineering Taskforce; and “SDP: Session Description Protocol”, IETF RFC 4566, M. Handley et al., 2006, Internet Engineering Taskforce, each of which is incorporated by reference in its entirety for any purpose.


By way of non-limiting example, the IETF SIP Protocol defines mechanism where parties may establish real-time sessions, tear down sessions, or renegotiate the connection for the session. SIP is used to negotiate audio, video, gaming, and other real-time sessions. SIP can be used for Internet telephone calls. In such embodiments, an initial SIP message may be sent from one side to the other indicating that they would like engaging in a call (“ringing” the other party), and indicating an IP address where audio may be sent to reach them. If the other side accepts the call, it replies with an IP address where it may receive audio, and the users can send media to each other. Subsequently, if the call is transferred (e.g., to another party, to a virtual machine (VM) server, or to a different phone device), SIP can be used to renegotiate the addresses where media should be sent.


Another function is the actual exchange of the real-time information (media). After negotiating how data is to be controlled, where it is to be sent, and how it is encoded, as described above, this function controls the transport of the data. For example, a mechanism to facilitate sending the real-time (e.g., media) packets is a combination of a two IETF protocols: RTP and RTP Control Protocol (RTCP). In some embodiments, RTP defines how to encapsulate the packets or frames of media, and provides a number of headers that help describe and transport the data. Among the information RTP provides fields to describe are: the type of data (payload type), which defines what encoding or codec is used/being sent; timestamps indicating the time various packets were sent; sequence numbers to identify the order of the packets and track lost packets; information about the source; and information that helps synchronize multiple streams (e.g., two audio streams for stereo, or video and audio streams that should be correlated). RTP also provides extensions allowing redundant data packets to be marked.


RTCP may be used to send information alongside the media streams, using a different logical communications channel or stream. As such, it is an “out-of-band” communications mechanism. RTCP sends periodic reports back and forth, allowing senders and receivers to understand how well the information is flowing between them. These statistics can be used to adjust the flow of information to account for slow network connections, lost packets, overwhelmed receivers, etc., and can also be used to determine the likely quality of the user experience (e.g., QoS). Actions may be taken in response to RTCP reports, such as increasing or lowering the quality of the source media and increasing or decreasing redundancy in response to lost packets. In some embodiments, instead of using a separate control channel, control information can be included in-band, within specially marked packets within the media stream (for example, directly within the RTP packets).


Other protocols may be used for streaming. By way of non-limiting example, the Real Time Messaging Protocol (RTMP) streams audio and video data for Flash applications. DASH, or Dynamic Adaptive Streaming over HTTP is a technique or protocol that can block media and transmit the blocked media over HTTP connections.



FIG. 1 illustrates system 100 for providing redundancy via a secondary channel to a consumer or small office. Embodiments of system 100 include a network telephone or video system. System 100 includes a Sender 101, sending Real-Time Stream 103 to Receiver 102 via Primary Network 104. Real-Time Stream 103 can include a variety of information that needs to be sent from the sender to the receiver in a timely manner, sensitive to delay, delivery time, etc. In an exemplary embodiment, Real-Time Stream 103 could be media for a phone call (e.g., the sender's voice being sent to the receiver, or to a service provider device such as a switch, soft-switch, gateway, or similar device), and other kinds of applications, such as home automation, home security, real-time information from sensors, video information, game information (e.g., position of a character, information about actions taken, etc.), and many other types of time critical information. In some embodiments, Real-Time Stream 103 is a telephone call, conveyed using IETF RTP protocol packets, and negotiated using IETF SIP protocol packets.


In various embodiments, Primary Network 104 is a packet-switched data network, in which information is broken into small blocks of information, or packets, to be sent across the network. For example, the primary network could be a wired connection to the public Internet (e.g., cable, DSL, fiber, etc.), wireless connection to the public Internet (e.g., WiMAX and the like), and any type of public or private data network over wired or wireless access media. By way of non-limiting example, the primary network can be: leased T-carrier line; Synchronous Optical Networking (SONET); Synchronous Digital Hierarchy (SDH); cable internet access; Digital Subscriber Line (DSL); Fiber-to-the-home (FTTH); Broadband over power lines (BPL); WiFi (e.g., based on Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard); Global System for Mobile Communications (GSM) Circuit Switched Data (CSD), General packet radio service (GPRS), and Enhanced Data rates for GSM Evolution (EDGE); Cellular Digital Packet Data (CDPD); Wideband Code Division Multiple Access (WCDMA); High Speed Packet Access (HSPA); Universal Mobile Telecommunications System (UMTS)-time-division duplexing (TDD); CDMA2000; Evolved High-Speed Packet Access (HSPA+); Worldwide Interoperability for Microwave Access (WiMAX); Long-Term Evolution (4G LTE); LTE Advanced; Mobile Broadband Wireless Access (MBWA); satellite broadband; and the like.


A second, physically independent network, Secondary Network 106, is also included in system 100. Selectively, Secondary Real-Time Stream 105 may be sent over Secondary Network 106 under certain conditions. In an exemplary embodiment, this could be a secondary wireless network from a mobile provider (e.g., 4G, WiMAX, etc.), a second broadband connection (e.g., cable, DSL, fiber, WiMAX, etc.), and a connection through another connected consumer device in the home (e.g., a mobile device such as a cellular phone, smart phone, phablet computer, tablet computer, notebook computer, and the like). Any of these networks can provide a backup connection in the case of the failure of Primary Network 104. Secondary Network 106 may be any type of public or private data network over wired or wireless access media, for example, as described in relation to Primary Network 104.


In embodiments where Primary Network 104 and Secondary Network 106 use a same type of access media, Primary Network 104 and Secondary Network 106 are different and distinct instances of the access media type. By way of non-limiting example, two separate cable lines, two separate DSL lines, two different mobile internet service providers (e.g., AT&T Mobility, Bouygues, China Mobile, China Unicorn; China Telecom, EE, E-Plus, KDDI, NTT DoCoMo, O2, Orange, SFR, SoftBank, Sprint, Mobile, Telekom, T-Mobile, Verizon Wireless, Vodaphone, Y!mobile, etc.), and the like.



FIG. 1 illustrates a simplified flow from Sender 101 to Receiver 102, but as would be readily appreciated by one of ordinary skill in the art, System 100 may be symmetric, supporting a bi-directional flow, or involve multiple senders and/or receivers (e.g., one-to-many or many-to-many flows). That is, the role of and term “Sender” or “Receiver” is a logical, not absolute one. Primary Network 104 and Secondary Network 106 will themselves may also be bi-directional (e.g., Receiver 102 can also send information to Sender 101). In the exemplary embodiment of a phone call being carried over the real-time stream, for example, there would be one flow in each direction, and at various times (depending on who is speaking) either party could be considered the sender or receiver.



FIG. 2 illustrates a simplified block diagram of exemplary system 200. Premises 290 may be a home office or small office (e.g., involving 1-10 workers) which receives separate independent connections from Primary Network 104 and Secondary Network 106. Various connections shown in FIG. 2 between each component (e.g., between Home Hub 230 and various access mechanisms 210, 260261 and 262) may be wired (e.g., Ethernet, USB, or similar) and/or wireless (e.g., WiFi, Bluetooth, or similar). In some embodiments, various end devices, such as computers, tablets, mobile phones, Digital Enhanced Cordless Telecommunications (DECT) phones, wired telephone handsets, etc. are connected to the Internet, directly over IP or over protocols through adapters. Primary Broadband Interface 210 connects end devices to the Internet, and on to various services, via Primary Network 104.


Some end devices, Device(s) 220, connect via a specialized Home Hub 230 to the Primary Broadband Interface 210 and on to Primary Network 104. Home Hub 230 provides additional services and capabilities beyond simple transmission of data, as described below. Additionally, some end devices, Direct Device(s) 240, may be connected to the primary network (via the primary broadband interface) without using home hub. That is, they may traverse other conventional networking devices such as adapters, switches, hubs, routers, gateways, etc., but not through the home hub. Device(s) 220, Direct Device(s) 240, and Home Hub 230 connect to one or more Remote Service(s) 250 Primary Network 104 to obtain services.


Additionally, Home Hub 230 has access to one or more separate network(s), Secondary Network 106. When things are operating normally, Primary Network 104 is used via Primary Broadband Interface 210, but in other circumstances (described below), Secondary Network 106 may be used, for example to send redundant information (e.g., to reconstruct the “bad”—corrupted and/or delayed—transmission on Primary Network 104) or (substantially) all information. For example, a checksum or error correcting code (ECC) approach is used, where additional bits are produced as a mathematical result of a calculation performed on the original bits. If the data is corrupted, the checksum or error correcting bits can be used to detect and/or even correct the corrupted or missing data. For example, at least one of a repetition code, parity bit, checksum, cyclic redundancy check (CRC), cryptographic hash function, error-correcting code (e.g., forward error correction (FEC) or channel coding), combinations thereof, and the like is used for error detection. By way of further non-limiting example, at least one of an error-correcting code (e.g., forward error correction (FEC) or channel coding), convolutional code, a block code (e.g., Reed-Solomon code, Hamming code, Hadamard code, Expander code, Golay code, Reed-Muller code, etc.), combinations thereof, and the like is used for error correction. By sending the redundant information (e.g., as described above for error detection and/or error correction) over the Secondary Network 106, such techniques can be used to detect and/or recover data lost over Primary Network 104.


Secondary Network 106 may be accessed in several ways. In some embodiments, the connection is through a dedicated Secondary Network Interface Device 260 (e.g., a second broadband service, WiMAX, and dedicated 4G modem/hotspot). Home Hub 230 may use Secondary Network Interface Device 260 to connect to Secondary Network 106 in order to access Remote Service 250.


In various embodiments, the connection to Secondary Network 106 is made through Security/Control System 261. Consumer and small office environments may have security and/or automation system(s). For example, Security/Control System 261 provides alarm services and allows remote control of lighting, cameras, sprinklers, etc. Security/Control System 261 can be wired to traditional telephone connections or via wired broadband connections, but increasingly, Security/Control System 261 incorporates or is connected to a wireless service, for example, through a cellular modem (3G/4G) that allows Security/Control System 261 to maintain a data connection even when wired phone lines and/or broadband connections are disrupted or tampered with. Home Hub 230 may connect to Security/Control System 261, taking advantage of a connection of Security/Control System 261 as Secondary Network 106 to access Remote Service 250.


In various embodiments, the connection to the secondary network is made through a Network Enabled Device Interface 262. For example, numerous network-enabled devices (e.g., network-capable consumer devices; not shown in FIG. 2) may be present in or about the home or small business. A network-enabled device is an electronic device, generally connected to other devices or networks via different wireless protocols such as Bluetooth, NFC, WiFi, 4G, and the like (e.g., as described in relation to Secondary Network 106), that can operate to some extent interactively and autonomously. Smart devices include, by way of non-limiting example, a cellular phone, smartphone, phablet, tablet computer, e-reader (also known as an e-book reader or e-book device), smartwatch, smart band, smart keychain, automobile providing an Internet connection (e.g., in-car internet generally provisioned through mobile phone data networks, such as those described in relation to Secondary Network 106), and gaming system, each having a respective network connection and the capability of sharing this connection. Home Hub 230 may use one or more of these network enabled device interfaces(s) as Secondary Network 106 to access Remote Service 250.


Home Hub 230 may be as simple as a special purpose home router, but in exemplary embodiments, Home Hub 230 is a home/small office communications device that provides some additional capabilities. For example, Home Hub 230 provides authentication, packet prioritization, and optimization properties supporting a communications system. By way of further non-limiting example, Home Hub 230 provides interfaces to connect non-IP devices (e.g., phones), via mechanisms such as Bluetooth, DECT, or conventional analog phone lines. In some embodiments Home Hub 230 interfaces with other devices to provide (or itself provide) home security and/or home automation functions. In addition, Home Hub 230 provides redundant network capabilities as described below.


Device(s) 220 connect to Home Hub 230 either directly (e.g., through the interfaces described above such as DECT, analog phone, Bluetooth, etc.) or via LAN Network 270 (e.g., provided by Home Hub 230 via WiFi, Ethernet, etc.). Device(s) 220 connected to LAN Network 270 or directly to the home hub using one of its interfaces can reach either Primary Network 104 or Secondary Network 106 as described below. In various embodiments, Device(s) 220 could be a telephone (e.g., a non-IP phone such as a DECT and/or Bluetooth handset), computer, or tablet connected via Home Hub 230, and using Remote Service 250 to provide telephony services.


In some embodiments, Home Hub 230 and/or Remote Service 250—independently, together, and/or in concert with one or more Device 220—determine the performance of Primary Network 104, and select between the primary network (e.g., via Primary Broadband Interface Device 210) and Secondary Network 106 (e.g., via interfaces 260, 261, and/or 262) to help ensure service is uninterrupted (e.g., at a desired QoS).


In various embodiments, Secondary Network 106 has a higher cost, requires more power, has more limited capabilities, etc. than Primary Network 104. Accordingly, there may be an incentive to continue monitoring Primary Network 104 and move traffic back to Primary Network 104 when and if service is again adequate (e.g., has an acceptable QoS). This will vary depending on the specific deployment and needs of the system. In an exemplary embodiment, Primary Network 104 may be a flat-rate broadband connection, while Secondary Network 106 is subject to billing parameters (e.g., a usage cap, bandwidth being charged in increments (such that the more data is sent over Secondary Network 106, the higher the bill), etc.) which create a sufficient financial incentive to use Primary Network 104. Remote Service 250 may alert the user or responsible party of usage on Secondary Network 106 to help prevent costs incurred by usage overruns, etc.


In some embodiments, Direct Device(s) 240 are connected directly to the Primary Broadband Interface Device 210—not via Home Hub 230—and are not able to take advantage of Secondary Network 106 without modification. Because they connect via the home hub, Devices 220 require no modification, as discussed below.


As a real-time session takes place, various mechanisms can be used to monitor the performance of the sessions. One major performance issue that can occur is the loss of packets of information. In response, packets may be sometimes be retransmitted, redundancy increased, or quality reduced. In addition, in various embodiments loss will indicate a need to use the Secondary Network 106. There are numerous ways to monitor the session performance, including monitoring of various buffer sizes to determine when packets are missing or lost. In some embodiments, a simplified “score boarding” mechanism is used to detect the rate of lost packets.



FIG. 3 illustrates scoreboard 300. Scoreboard 300 includes a List of Expected Packets (or payloads) 310 based on an identifier (e.g., sequence number, packet ID, etc.), shown in FIG. 3 as letters A, B, C, etc. (other identifiers may be used). Each expected packet/payload may be checked off (e.g., using a mechanism such as flipping/toggling a bit on or off) as it arrives on List of Received Packets 320, again based on some identifier for each packet. In FIG. 3, packets A, B, and D have arrived, but C has failed to arrive. As time progresses beyond the time for acceptable latency (i.e., some number of packets), the scoreboard is examined to determine how many packets have failed to arrive. If an unacceptable number have not arrived, the receiver can respond accordingly (e.g., triggering an action such as changing redundancy level, reducing encoding quality, initiating the use of a secondary channel, performing/capturing diagnostics, etc.). Scoreboard 300 offers the benefit of simplicity and effectiveness.


In addition (or alternatively) to the very simple score boarding mechanism above, Home Hub 230, Remote Service 250, and/or one of Device 220 may use other mechanisms to detect degradation in performance and initiate a change to Secondary Network 106. For example, by detecting an increase in packet loss some other way, changes to jitter buffer size, detecting packets are significantly delayed, directly measuring reductions in audio quality, etc.


Referring back to FIG. 2, in various embodiments Device(s) 220 is connected directly to an interface on Home Hub 230 other than via LAN 270, and Home Hub 230 then connects to Remote Service 250. For example, Device(s) 220 may be an analog phone connected directly to Home Hub 230. In some embodiments, Home Hub 230 or Remote Service 250 detects the degradation and initiates (e.g., using a signal) a switch to Secondary Network 106. This signaling can occur in a number of ways. In an exemplary implementation, SIP is used to set up the calls. While the IP address of Remote Service 250 may be unchanged, special headers, URL parameters, message bodies, or other aspects of SIP can be used between the Home Hub 230 and Remote Service 250 (initiated by either side), to request that Home Hub 230 and Remote Service 250 communicate via Secondary Network 106. In various embodiments, this message could also be carried as a special control messages in the media itself (RTP or RTCP message) rather than in the signaling channel. Other protocols can be used. By way of non-limiting example, one or more of the ITU H.323 family of protocols, Extensible Messaging and Presence Protocol (XMPP), Jingle (e.g., an extension to XMPP adding peer-to-peer (P2P) session control (signaling) for multimedia interactions such as in Voice over IP (VoIP) or videoconferencing communications), and the like are used.


In some embodiments, Device(s) 220 is an IP device connected over LAN 270, and Home Hub 230 actively participate in the session. That is, Home Hub 230 is aware of the session and mediating it in some way that allows it to intervene, for example, by relaying the media packets actively and/or serving as a back-to-back user agent (B2BUA). For example, a B2BUA is a logical network element in SIP applications, where SIP is a signaling protocol to manage multimedia Voice over Internet Protocol (VoIP) telephone calls. A B2BUA operates between both end points of a phone call or communications session, divides the communication channel into two call legs, and mediates all SIP signaling between both ends of the call, from call establishment to termination. Any of the Home Hub 230, Device(s) 220, and Remote Service 250 may notice the degradation, and signal the others to switch to the secondary network. As Home Hub 230 participates in the call in some material way—that is, it is aware of the call and the media flowing through it—Home Hub 230 and/or Remote Service 250 can signal to each other to use the secondary channel, as described above.


In various embodiments, Device(s) 220 is an IP device connected over the LAN 270, but Home Hub 230 is not actively participating in the call (e.g., it may be routing packets, but is not involved in and/or aware of the actual media session traversing it). However, Remote Service 250 is aware that the Home Hub 230 has access to a Secondary Network 106. In this case, a novel mechanism may be used to move the traffic over to the secondary network.


Prior to detecting conditions under which there is a switch to the Secondary Network 106, or at such time a switch to Secondary Network 106 is indicated, in some embodiments, Home Hub 230 and Remote Service 250 communicate to determine if a secondary channel is available. If so, the Home Hub 230 reserves some number of private IP addresses, and may use these internally on the LAN 270 as needed as a mechanism to allow Device(s) 220 connected to the LAN to reach the remote service over Secondary Network 106. Any packets sent to this private address(es) are translated by the home hub to the globally routable address(es) of the remote service, but are sent over Secondary Network 106, rather than Primary Network 104.


Packets sent to Device(s) 220 from Remote Service 250 over the secondary network may be translated by Home Hub 230 to appear as if they originated from the reserved private address(es), rather than the globally routable address(es) of the remote service. The effect of this is to give the remote service two addresses as seen from the device: the service's normal, globally routable address, for which traffic is carried over the primary network, and a second, private address on the LAN, to and from which traffic will have addresses translated, and be routed over Secondary Network 106.



FIG. 4 illustrates some embodiments of exemplary system 400 in more detail. Device(s) 220 is connected to LAN 270, and is unmodified in any way. Device(s) 220 is unaware Home Hub 230 has second network capabilities. Remote Service 250 is reachable over the Internet at globally routable address 162.209.125.137. Home Hub 230 reserves an address from the defined set of private, non-globally routable addresses, and assigns this on the LAN to Remote Service 250 as required. In this case, Home Hub 230 assigns 10.0.0.137 (a private address as defined by RFC 1918) to Remote Service 250. This transaction may occur at any time prior to the use of the secondary channel.


When Device(s) 220 first places a call to Remote Service 250, it uses the (well known) globally routable address 162.209.125.137 to reach the service, in step A. Home Hub 230 uses Primary Broadband Interface 210 to reach Primary Network 104 and pass the information to the remote service, in steps B and C. If the session (e.g., a phone call) proceeds normally, the session remains on Primary Network 104. If however, the connection degrades over time, Remote Service 250 may send a control message back to Device(s) 220 requesting information be sent over Secondary Network 106, and providing the reserved address 10.0.0.137 negotiated between Home Hub 230 and Remote Service 250 at some point before (including immediately before) the switch is made. Device(s) 220 may send the data for the session to 10.0.0.137, in step D. Home Hub 230 translates this to the globally routed address 162.209.125.137, sending it over Secondary Network 106 through Secondary Broadband Interface 260 in steps E and F.


Home Hub 230 could also use Security/Control System 261, Network Enabled Device Interface 262, or some other mechanism to reach Secondary Network 106. Similarly, any messages arriving at Home Hub 230 from Remote Service 250 arriving over the secondary network and intended for the device are translated back to appear as if originating from 10.0.0.137 before being sent on, ensuring that Device(s) 220 operates as if 10.0.0.137 is the new/correct address of Remote Service 250.


Note that translation of addresses may simply be at the IP level (only modifying IP address headers), but may also include application-specific packet inspection and rewriting of internal addresses used by the protocol (i.e., application layer address changes), depending on the requirements of the application and the particular deployment.



FIG. 5 is a flowchart 500 illustrating decisions made by the Home Hub 230 in order to route a message. A packet arrives at Home Hub 230 in step 510. At step 520, it is determined if the packet has arrived from the Internet or the LAN. If it is from the LAN, the packet is next checked at step 530 to see if the address the packet was addressed to is a private address that the home hub has mapped to Remote Service 250. If so, Home Hub 230 looks up the global address the local address is mapped to and translates the address in the packet at step 540. In step 550, the packet is then sent over to Secondary Network 106. If the packet received from the LAN was not addressed to a mapped private address, the packet address is not translated, and it is forwarded over the Primary Network 104 at step 560. The process then repeats as new packets arrive.


If the packet reaching the Home Hub 230 is determined to come from the Internet in step 520, the packet is next examined to see if it arrived from the Secondary Network 106, and if it was received from a Remote Service 250 that is mapped to a local address in step 570. If both conditions are true, the local reserved address corresponding to this remote service is looked up, and the packet translated to show as originating from this local address in step 580. If either condition is not true, step 580 is skipped. In either case, the packet is forwarded on to the LAN in step 590. The method may repeat as new packets arrive.


In some embodiments, Device(s) 220 requires no modification to take advantage of Secondary Network 106, and requires no knowledge that Home Hub 230 has a connection to Secondary Network 106. Exemplary embodiments pass the signal between Remote Service 250 and unmodified Device(s) 220 to change addresses using a SIP INVITE message. In SIP, the INVITE message is used to send requests to establish a session, including information on where (e.g., IP address or hostname) and the format to send the media. Later INVITE messages can be sent to update this information (e.g., re-INVITE mechanism), for example to transfer a call or send it to voicemail.


In various embodiments, the establishment or discontinuing of a new channel over Secondary Network 106 is performed (as needed) by sending a new SIP INVITE message containing either the globally routable address or a reserved private address, appearing to Device(s) 220 as a simple transfer. These results may be accomplished in SIP in a number of different ways, by way of non-limiting example, sending a new SIP INVITE (the re-INVITE mechanism) above, SIP REFER or NOTIFY messages, some other SIP messages, a new mechanisms or messages defined by the IETF, new or proprietary Uniform Resource Identifier (URI) parameters, new or proprietary headers, etc. Additionally, other protocols that perform similar session establishment capabilities (e.g., H.323, XMPP, etc.) could be used.


In some embodiments, Remote Service 250 communicates a switch from Primary Network 104 and Secondary Network 106 (and vice versa) to the Device(s) 220 within the media stream (e.g., carried by RTP and RTCP) or a different logical channel. For example, this signaling is in-band over the actual media stream using IETF RTP messages with special headers or payload packages. By way of further non-limiting example, these messages are sent over the control portion of the media channel, for example, in IETF RTPC messages. By way of further example, these messages could consist of messages in another media or real-time control protocol. In yet another example, this information could be conveyed over a different logical channel, potentially using a proprietary protocol. While none of these methods are standard behavior of current devices (unlike some of the embodiments above), and would require the device to be modified, the modifications are advantageous.


In various embodiments, Remote Service 250 communicates with Device(s) 220 in advance (e.g., prior to experiencing a lost and/or delayed packets), informing of it of the availability of an address that can be used to reach it via Secondary Network 106 should the need arise. Such an approach requires modification of Device(s) 220, including some level of awareness of Secondary Network 106 by the device. In this way, even in situations in which Primary Network 104 completely fails can be handled. Requests to use Secondary Network 106 can be sent in numerous ways—for example, by sending a new SIP INVITE, SIP REFER or NOTIFY messages, other SIP messages, new mechanisms or messages defined by the IETF, new or proprietary URI parameters, new or proprietary headers, etc.; by using a different protocol with similar session establishment capabilities; by messages inside the media stream; by using messages in the media control stream; by using messages another logical connection; and the like.



FIG. 6 is a flowchart for method 600 of using Secondary Network 106. At step 610, the Primary Network 104 is used for communications. At step 620, a determination is made whether network problems are detected by any of the participating parties (e.g., Home Hub 230, Remote Service 250, and in some cases Device(s) 220). If problems are not detected, the parties continue to use Primary Network 104. If a problem is detected, Home Hub 230 and Remote Service 250 negotiate a second channel in step 630. Step 630 is optional, because negotiating a second channel may have been done in advance, for example, when Home Hub 230 boots or authenticates. At step 640, it is determined whether Device(s) 220 is connected to LAN 270 and is communicating directly with Remote Service 250. If so, Remote Service 250 signals directly to Device(s) 220 in step 650 with a new, local address to use to reach it—the address mapped over the secondary network by Home Hub 230.


In step 660, Home Hub 230 begins using Secondary Network 106, translating packets as needed for devices connected over the LAN 270. At step 670, the participating devices check if the Primary Network 104 has improved, and if so, return to using Primary Network 104 in step 680. Otherwise, the devices continue to use Secondary Network 106, checking Primary Network 104 again periodically to see if it has improved.


Detecting restoration of an acceptable quality of service (e.g., problem detected at Step 620 is resolved or mitigated) may be performed actively and/or passively. For example, Home Hub 230 actively transmits probe traffic (e.g., test/diagnostic packets) over Primary Network 104 to Remote Service 250 to ascertain performance of Primary Network 104 (e.g., does network bandwidth (measured in bits per second (bps), megabits per second (Mbps), gigabits per second (Gbps), and the like) satisfy a (predetermined) threshold). The probe traffic may be from a ping utility (e.g., Internet Control Message Protocol (ICMP) echo request packets sent to Remote Service 250). Using the presence and/or absence of an ICMP response (e.g., from Remote Service 250), the time from transmission to reception (e.g., round-trip time) and any packet loss may be measured and the measurements compared to preset or user-defined limits. The probe traffic may (alternatively or additionally) be simulated data traffic, such as (simulated) streamed media (e.g., audio and video). Home Hub 230 may also analyze passive data (e.g., not responsive to probe packets and arising during the course of regular operation) originating and/or terminating over Primary Network 104 and ascertain, for example, whether the rate of incoming packets increase and/or a number (e.g., fraction, percentage, etc.) of dropped/discarded packets decreases (e.g., above or below a respective predetermined threshold).


In some embodiments, Home Hub 230 and Remote Service 250 pre-negotiate the availability of Secondary Network 106 and private network mappings. For example, they could negotiate the connection address(es) at boot or authentication time of Home Hub 230.


In various embodiments, Home Hub 230 and Remote Service 250 negotiate the use of Secondary Network 106 only as needed (e.g., on an as needed or demand basis). This mechanism allows for more than one secondary network, with different choices being made available and used depending upon the quality, cost to transmit information, available bandwidth, etc.


For each of the foregoing descriptions, in all cases the role of sender and receiver, as well as primary and secondary designations are logical roles, and may be reversed.



FIG. 7 illustrates an exemplary computer system 700 that may be used to implement some embodiments of the present invention. The computer system 700 in FIG. 7 may be implemented in the contexts of the likes of computing systems, networks, servers, or combinations thereof. The computer system 700 in FIG. 7 includes one or more processor unit(s) 710 and main memory 720. Main memory 720 stores, in part, instructions and data for execution by processor unit(s) 710. Main memory 720 stores the executable code when in operation, in this example. The computer system 700 in FIG. 7 further includes a mass data storage 730, portable storage device 740, output devices 750, user input devices 760, a graphics display system 770, and peripheral device(s) 780.


The components shown in FIG. 7 are depicted as being connected via a single bus 790. The components may be connected through one or more data transport means. Processor unit(s) 710 and main memory 720 are connected via a local microprocessor bus, and the mass data storage 730, peripheral device(s) 780, portable storage device 740, and graphics display system 770 are connected via one or more input/output (I/O) buses.


Mass data storage 730, which can be implemented with a magnetic disk drive, solid state drive, or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor unit(s) 710. Mass data storage 730 stores the system software for implementing embodiments of the present disclosure for purposes of loading that software into main memory 720.


Portable storage device 740 operates in conjunction with a portable non-volatile storage medium, such as a flash drive, floppy disk, compact disk, digital video disc, or Universal Serial Bus (USB) storage device, to input and output data and code to and from the computer system 700 in FIG. 7. The system software for implementing embodiments of the present disclosure is stored on such a portable medium and input to the computer system 700 via the portable storage device 740.


User input devices 760 can provide a portion of a user interface. User input devices 760 may include one or more microphones, an alphanumeric keypad, such as a keyboard, for inputting alphanumeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys. User input devices 760 can also include a touchscreen. Additionally, the computer system 700 as shown in FIG. 7 includes output devices 750. Suitable output devices 750 include speakers, printers, network interfaces, and monitors.


Graphics display system 770 include a liquid crystal display (LCD) or other suitable display device. Graphics display system 770 is configurable to receive textual and graphical information and processes the information for output to the display device.


Peripheral device(s) 780 may include any type of computer support device to add additional functionality to the computer system.


The components provided in the computer system 700 in FIG. 7 are those typically found in computer systems that may be suitable for use with embodiments of the present disclosure and are intended to represent a broad category of such computer components that are well known in the art. Thus, the computer system 700 in FIG. 7 can be a personal computer (PC), hand held computer system, telephone, mobile computer system, workstation, tablet, phablet, mobile phone, server, minicomputer, mainframe computer, wearable, or any other computer system. The computer may also include different bus configurations, networked platforms, multi-processor platforms, and the like. Various operating systems may be used including UNIX, LINUX, WINDOWS, MAC OS, PALM OS, QNX ANDROID, IOS, CHROME, and other suitable operating systems.


Some of the above-described functions may be composed of instructions that are stored on storage media (e.g., computer-readable medium). The instructions may be retrieved and executed by the processor. Some examples of storage media are memory devices, tapes, disks, and the like. The instructions are operational when executed by the processor to direct the processor to operate in accord with the technology. Those skilled in the art are familiar with instructions, processor(s), and storage media.


In some embodiments, the computing system 700 may be implemented as a cloud-based computing environment, such as a virtual machine operating within a computing cloud. In other embodiments, the computing system 700 may itself include a cloud-based computing environment, where the functionalities of the computing system 700 are executed in a distributed fashion. Thus, the computing system 700, when configured as a computing cloud, may include pluralities of computing devices in various forms, as will be described in greater detail below.


In general, a cloud-based computing environment is a resource that typically combines the computational power of a large grouping of processors (such as within web servers) and/or that combines the storage capacity of a large grouping of computer memories or storage devices. Systems that provide cloud-based resources may be utilized exclusively by their owners or such systems may be accessible to outside users who deploy applications within the computing infrastructure to obtain the benefit of large computational or storage resources.


The cloud is formed, for example, by a network of web servers that comprise a plurality of computing devices, such as the computing system 700, with each server (or at least a plurality thereof) providing processor and/or storage resources. These servers manage workloads provided by multiple users (e.g., cloud resource customers or other users). Typically, each user places workload demands upon the cloud that vary in real-time, sometimes dramatically. The nature and extent of these variations typically depends on the type of business associated with the user.


It is noteworthy that any hardware platform suitable for performing the processing described herein is suitable for use with the technology. The terms “computer-readable storage medium” and “computer-readable storage media” as used herein refer to any medium or media that participate in providing instructions to a CPU for execution. Such media can take many forms, including, but not limited to, non-volatile media, volatile media and transmission media. Non-volatile media include, for example, optical, magnetic, and solid-state disks, such as a fixed disk. Volatile media include dynamic memory, such as system RAM. Transmission media include coaxial cables, copper wire and fiber optics, among others, including the wires that comprise one embodiment of a bus. Transmission media can also take the form of acoustic or light waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, a hard disk, magnetic tape, any other magnetic medium, a CD-ROM disk, digital video disk (DVD), any other optical medium, any other physical medium with patterns of marks or holes, a RAM, a PROM, an EPROM, an EEPROM, a FLASH memory, any other memory chip or data exchange adapter, a carrier wave, or any other medium from which a computer can read.


Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to a CPU for execution. A bus carries the data to system RAM, from which a CPU retrieves and executes the instructions. The instructions received by system RAM can optionally be stored on a fixed disk either before or after execution by a CPU.


Computer program code for carrying out operations for aspects of the present technology may be written in any combination of one or more programming languages, including an object oriented programming language such as JAVA, SMALLTALK, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).


The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present technology has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. Exemplary embodiments were chosen and described in order to best explain the principles of the present technology and its practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.


Aspects of the present technology are described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.


These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.


The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.


The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present technology. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.


The description of the present technology has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. Exemplary embodiments were chosen and described in order to best explain the principles of the present technology and its practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims
  • 1. A method for managing alternative networks comprising: receiving first data packets at a third interface from a computing device, the first data packets including primary data and redundant data, the redundant data being generated from the primary data using at least one of a checksum and an error-correcting code (ECC), the third interface being coupled to the computing device at a premises;sending the primary data in second data packets to a service using a first interface, the first interface being coupled to a first broadband connection received at the premises, the first broadband connection being coupled to the service outside the premises using a first data network; andproviding the redundant data in third data packets to the service using a second interface, the service recovering lost ones of the second data packets and/or corrupted ones of the second data packets using the primary data and the redundant data, the second interface being coupled to a second broadband connection received at the premises, the second broadband connection being coupled to the service outside the premises using a second data network and being different from the first broadband connection.
  • 2. The method of claim 1, wherein an analog telephone is communicatively coupled to the computing device.
  • 3. The method of claim 1, further comprising: providing a quality of service provided by the first data network to the computing device,wherein the computing device provides the third data packets responsive to the quality of service.
  • 4. The method of claim 3, further comprising: determining the quality of service provided by the first data network, the determining including: measuring at least one of a data rate and a number of lost packets over the first data network, andcomparing the measurements to at least one of a predetermined data rate and predetermined number of lost packets.
  • 5. The method of claim 1, further comprising: determining a quality of service provided by the first data network, andrequesting the third data packets from the service using the determining.
  • 6. The method of claim 5, wherein the determining the quality of service provided by the first data network comprises: measuring at least one of a data rate and a number of lost packets over the first data network, andcomparing the measurements to at least one of a predetermined data rate and predetermined number of lost packets.
  • 7. The method of claim 1, wherein the recovering the lost ones of the second data packets and/or the corrupted ones of the second data packets uses one or more of a parity bit, the checksum, and the ECC.
  • 8. The method of claim 7, wherein the ECC is at least one of a: repetition code, cyclic redundancy check (CRC), cryptographic hash function, forward error correction (FEC), and channel coding.
  • 9. The method of claim 7, wherein the ECC is at least one of a: convolutional code, block code, Reed-Solomon code, Hamming code, Hadamard code, Expander code, Golay code, and Reed-Muller code.
  • 10. The method of claim 1, wherein: the first broadband connection is at least one of a leased T-carrier line, Synchronous Optical Networking (SONET), Synchronous Digital Hierarchy (SDH), cable internet access, Digital Subscriber Line (DSL), Fiber-to-the-home (FTTH), Broadband over power lines (BPL), Wi-Fi, WiMAX, mobile broadband, and satellite broadband,the second broadband connection is at least one of a leased T-carrier line, Synchronous Optical Networking (SONET), Synchronous Digital Hierarchy (SDH), cable internet access, Digital Subscriber Line (DSL), Fiber-to-the-home (FTTH), Broadband over power lines (BPL), Wi-Fi, WiMAX, and mobile broadband, andthe third interface is coupled to a local data network, the local data network including at least one of a wired local area network (LAN), wireless LAN, and wireless communications using one or more of Digital Enhanced Cordless Telecommunications (DECT), Bluetooth, and Bluetooth low energy.
  • 11. A system for managing alternative networks comprising: a first interface coupled to a first broadband connection received at a premises, the first broadband connection being coupled to a service outside the premises using a first data network;a second interface coupled to a second broadband connection received at the premises, the second broadband connection being coupled to the service outside the premises using a second data network and being different from the first broadband connection;a third interface coupled to a computing device at the premises;a processor coupled to the first, second, and third interfaces; anda memory coupled to the processor, the memory storing instructions executable by the processor to perform a method comprising: receiving first data packets at the third interface from the computing device, the first data packets including primary data and redundant data, the redundant data being generated from the primary data using at least one of a checksum and an error-correcting code (ECC);sending the primary data in second data packets to the service using the first interface; andproviding the redundant data in third data packets to the service using the second interface, the service recovering lost ones of the second data packets and/or corrupted ones of the second data packets using the primary data and the redundant data.
  • 12. The system of claim 11, further comprising: an analog telephone communicatively coupled to the computing device.
  • 13. The system of claim 11, wherein the method further comprises: providing a quality of service provided by the first data network to the computing device,wherein the computing device provides the third data packets responsive to the quality of service.
  • 14. The system of claim 13, wherein the method further comprises: determining the quality of service provided by the first data network, the determining including: measuring at least one of a data rate and a number of lost packets over the first data network, andcomparing the measurements to at least one of a predetermined data rate and predetermined number of lost packets.
  • 15. The system of claim 11, wherein the method further comprises: determining a quality of service provided by the first data network; andrequesting the third data packets from the service using the determining.
  • 16. The system of claim 15, wherein the determining the quality of service provided by the first data network comprises: measuring at least one of a data rate and a number of lost packets over the first network, andcomparing the measurements to at least one of a predetermined data rate and predetermined number of lost packets.
  • 17. The system of claim 11, wherein the recovering the lost ones of the second data packets and/or the corrupted ones of the second data packets uses one or more of a parity bit, the checksum, and the ECC.
  • 18. The system of claim 17, wherein the ECC is at least one of a: repetition code, cyclic redundancy check (CRC), cryptographic hash function, forward error correction (FEC), and channel coding.
  • 19. The system of claim 17, wherein the ECC is at least one of a: convolutional code, block code, Reed-Solomon code, Hamming code, Hadamard code, Expander code, Golay code, and Reed-Muller code.
  • 20. The system of claim 11, wherein: the first broadband connection is at least one of a leased T-carrier line, Synchronous Optical Networking (SONET), Synchronous Digital Hierarchy (SDH), cable internet access, Digital Subscriber Line (DSL), Fiber-to-the-home (FTTH), Broadband over power lines (BPL), Wi-Fi, WiMAX, mobile broadband, and satellite broadband,the second broadband connection is at least one of a leased T-carrier line, Synchronous Optical Networking (SONET), Synchronous Digital Hierarchy (SDH), cable internet access, Digital Subscriber Line (DSL), Fiber-to-the-home (FTTH), Broadband over power lines (BPL), Wi-Fi, WiMAX, and mobile broadband, andthe third interface is coupled to a local data network, the local data network including at least one of a wired local area network (LAN), wireless LAN, and wireless communications using one or more of Digital Enhanced Cordless Telecommunications (DECT), Bluetooth, and Bluetooth low energy.
CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 14/708,132, filed May 8, 2015 and issued Dec. 13, 2016, as U.S. Pat. No. 9,521,069, which is hereby incorporated by reference herein in its entirety, including all references and appendices cited therein.

US Referenced Citations (282)
Number Name Date Kind
5425085 Weinberger et al. Jun 1995 A
5463595 Rodhall et al. Oct 1995 A
5519769 Weinberger et al. May 1996 A
5796736 Suzuki Aug 1998 A
5991301 Christie Nov 1999 A
5999611 Tatchell et al. Dec 1999 A
6023724 Bhatia et al. Feb 2000 A
6104711 Voit Aug 2000 A
6282574 Voit Aug 2001 B1
6298064 Christie Oct 2001 B1
6304572 Christie Oct 2001 B1
6377938 Block et al. Apr 2002 B1
6452932 Christie Sep 2002 B1
6463052 Christie Oct 2002 B1
6473429 Christie Oct 2002 B1
6487197 Elliott Nov 2002 B1
6577638 Tashiro et al. Jun 2003 B1
6615264 Stoltz et al. Sep 2003 B1
6633561 Christie Oct 2003 B2
6661340 Saylor et al. Dec 2003 B1
6665429 Christie Dec 2003 B1
6697358 Bernstein Feb 2004 B2
6714545 Hugenberg et al. Mar 2004 B1
6775267 Kung Aug 2004 B1
6778517 Lou et al. Aug 2004 B1
6778528 Blair et al. Aug 2004 B1
6781983 Armistead Aug 2004 B1
6914900 Komatsu et al. Jul 2005 B1
6934258 Smith et al. Aug 2005 B1
7113090 Saylor et al. Sep 2006 B1
7124506 Yamanashi et al. Oct 2006 B2
7127043 Morris Oct 2006 B2
7127506 Schmidt et al. Oct 2006 B1
7154891 Callon Dec 2006 B1
7280495 Zweig et al. Oct 2007 B1
7295660 Higginbotham et al. Nov 2007 B1
7342925 Cherchali et al. Mar 2008 B2
7376124 Lee et al. May 2008 B2
7394803 Petit-Huguenin et al. Jul 2008 B1
7733850 Croak et al. Jun 2010 B1
8140392 Altberg et al. Mar 2012 B2
8331547 Smith et al. Dec 2012 B2
8350694 Trundle et al. Jan 2013 B1
8515021 Farrand et al. Aug 2013 B2
8634520 Morrison et al. Jan 2014 B1
8804697 Capper et al. Aug 2014 B1
8837698 Altberg et al. Sep 2014 B2
9225626 Capper et al. Dec 2015 B2
9319531 Capper et al. Apr 2016 B1
9386148 Farrand et al. Jul 2016 B2
9386414 Mayor et al. Jul 2016 B1
9426288 Farrand et al. Aug 2016 B2
9521069 Gillon et al. Dec 2016 B2
9560198 Farrand et al. Jan 2017 B2
9633547 Farrand et al. Apr 2017 B2
9667782 Farrand et al. May 2017 B2
9787611 Gillon et al. Oct 2017 B2
9905103 Hsieh Feb 2018 B2
9929981 Gillon et al. Mar 2018 B2
10009286 Gillon et al. Jun 2018 B2
20010053194 Johnson Dec 2001 A1
20020016718 Rothschild et al. Feb 2002 A1
20020035556 Shah et al. Mar 2002 A1
20020037750 Hussain et al. Mar 2002 A1
20020038167 Chirnomas Mar 2002 A1
20020085692 Katz Jul 2002 A1
20020130784 Suzuki et al. Sep 2002 A1
20020133614 Weerahandi et al. Sep 2002 A1
20020140549 Tseng Oct 2002 A1
20020165966 Widegren et al. Nov 2002 A1
20030027602 Han et al. Feb 2003 A1
20030058844 Sojka et al. Mar 2003 A1
20030099334 Contractor May 2003 A1
20030119492 Timmins et al. Jun 2003 A1
20030141093 Tirosh Jul 2003 A1
20030164877 Murai Sep 2003 A1
20030184436 Seales et al. Oct 2003 A1
20030189928 Xiong Oct 2003 A1
20040001512 Challener et al. Jan 2004 A1
20040010472 Hilby et al. Jan 2004 A1
20040010569 Thomas et al. Jan 2004 A1
20040017803 Lim et al. Jan 2004 A1
20040059821 Tang et al. Mar 2004 A1
20040086093 Schranz May 2004 A1
20040090968 Kimber et al. May 2004 A1
20040105444 Korotin et al. Jun 2004 A1
20040160956 Hardy et al. Aug 2004 A1
20040235509 Burritt et al. Nov 2004 A1
20050027887 Zimler et al. Feb 2005 A1
20050036590 Pearson et al. Feb 2005 A1
20050074114 Fotta et al. Apr 2005 A1
20050078681 Sanuki et al. Apr 2005 A1
20050089018 Schessel Apr 2005 A1
20050097222 Jiang et al. May 2005 A1
20050105708 Kouchri et al. May 2005 A1
20050141485 Miyajima et al. Jun 2005 A1
20050152339 Scott et al. Jul 2005 A1
20050169247 Chen Aug 2005 A1
20050180549 Chiu et al. Aug 2005 A1
20050222820 Chung Oct 2005 A1
20050238034 Gillespie et al. Oct 2005 A1
20050246174 DeGolia Nov 2005 A1
20050259637 Chu et al. Nov 2005 A1
20060007915 Frame Jan 2006 A1
20060009240 Katz Jan 2006 A1
20060013195 Son et al. Jan 2006 A1
20060059238 Slater et al. Mar 2006 A1
20060071775 Otto et al. Apr 2006 A1
20060092011 Simon et al. May 2006 A1
20060114894 Cherchali et al. Jun 2006 A1
20060140352 Morris Jun 2006 A1
20060156251 Suhail et al. Jul 2006 A1
20060167746 Zucker Jul 2006 A1
20060187898 Chou et al. Aug 2006 A1
20060187900 Akbar Aug 2006 A1
20060243797 Apte et al. Nov 2006 A1
20060251048 Yoshino et al. Nov 2006 A1
20060258341 Miller et al. Nov 2006 A1
20060259767 Mansz et al. Nov 2006 A1
20060268828 Yarlagadda Nov 2006 A1
20060268848 Larsson et al. Nov 2006 A1
20070030161 Yang Feb 2007 A1
20070036314 Kloberdans et al. Feb 2007 A1
20070037560 Yun et al. Feb 2007 A1
20070037605 Logan Feb 2007 A1
20070041517 Clarke et al. Feb 2007 A1
20070049342 Mayer et al. Mar 2007 A1
20070054645 Pan Mar 2007 A1
20070061735 Hoffberg et al. Mar 2007 A1
20070067219 Altberg et al. Mar 2007 A1
20070071212 Quittek et al. Mar 2007 A1
20070118750 Owen et al. May 2007 A1
20070121593 Vance et al. May 2007 A1
20070121596 Kurapati et al. May 2007 A1
20070132844 Katz Jun 2007 A1
20070133757 Girouard et al. Jun 2007 A1
20070153776 Joseph et al. Jul 2007 A1
20070165811 Reumann et al. Jul 2007 A1
20070183407 Bennett et al. Aug 2007 A1
20070203999 Townsley et al. Aug 2007 A1
20070223455 Chang et al. Sep 2007 A1
20070238472 Wanless Oct 2007 A1
20070255702 Orme Nov 2007 A1
20070283430 Lai et al. Dec 2007 A1
20070298772 Owens et al. Dec 2007 A1
20080049748 Bugenhagen Feb 2008 A1
20080062997 Nix Mar 2008 A1
20080075248 Kim Mar 2008 A1
20080075257 Nguyen et al. Mar 2008 A1
20080084975 Schwartz Apr 2008 A1
20080089325 Sung Apr 2008 A1
20080097819 Whitman Apr 2008 A1
20080111765 Kim May 2008 A1
20080118039 Elliot et al. May 2008 A1
20080125095 Mornhineway et al. May 2008 A1
20080144625 Wu et al. Jun 2008 A1
20080144884 Habibi Jun 2008 A1
20080159515 Rines Jul 2008 A1
20080168145 Wilson Jul 2008 A1
20080196099 Shastri Aug 2008 A1
20080200142 Abdel-Kader et al. Aug 2008 A1
20080205386 Purnadi et al. Aug 2008 A1
20080225749 Peng et al. Sep 2008 A1
20080247382 Verma Oct 2008 A1
20080247401 Bhal et al. Oct 2008 A1
20080270457 Zilbershtein et al. Oct 2008 A1
20080298348 Frame et al. Dec 2008 A1
20080313297 Heron et al. Dec 2008 A1
20080316946 Capper et al. Dec 2008 A1
20090100178 Gonzales et al. Apr 2009 A1
20090106318 Mantripragada et al. Apr 2009 A1
20090135008 Kirchmeier et al. May 2009 A1
20090168755 Peng et al. Jul 2009 A1
20090213999 Farrand et al. Aug 2009 A1
20090224931 Dietz et al. Sep 2009 A1
20090240586 Ramer et al. Sep 2009 A1
20090253428 Bhatia et al. Oct 2009 A1
20090264093 Rothschild Oct 2009 A1
20090295572 Grim, III et al. Dec 2009 A1
20090303042 Song et al. Dec 2009 A1
20090319271 Gross Dec 2009 A1
20100034121 Bozionek Feb 2010 A1
20100046530 Hautakorpi et al. Feb 2010 A1
20100046731 Gisby et al. Feb 2010 A1
20100098034 Tang et al. Apr 2010 A1
20100098058 Delangis Apr 2010 A1
20100098235 Cadiz et al. Apr 2010 A1
20100114896 Clark et al. May 2010 A1
20100136982 Zabawskyj et al. Jun 2010 A1
20100158223 Fang et al. Jun 2010 A1
20100191829 Cagenius Jul 2010 A1
20100229452 Suk Sep 2010 A1
20100277307 Horton et al. Nov 2010 A1
20100278173 Dalton et al. Nov 2010 A1
20100302025 Script Dec 2010 A1
20110047031 Weerasinghe Feb 2011 A1
20110054689 Nielsen et al. Mar 2011 A1
20110111728 Ferguson et al. May 2011 A1
20110140868 Hovang Jun 2011 A1
20110170680 Chislett et al. Jul 2011 A1
20110183652 Eng et al. Jul 2011 A1
20110265145 Prasad et al. Oct 2011 A1
20120010955 Ramer et al. Jan 2012 A1
20120027191 Baril et al. Feb 2012 A1
20120035993 Nangia Feb 2012 A1
20120036576 Iyer Feb 2012 A1
20120047442 Nicolaou et al. Feb 2012 A1
20120092158 Kumbhar et al. Apr 2012 A1
20120099716 Rae et al. Apr 2012 A1
20120284778 Chiou et al. Nov 2012 A1
20120320905 Ilagan Dec 2012 A1
20120329420 Zotti et al. Dec 2012 A1
20130018509 Korus Jan 2013 A1
20130035774 Warren et al. Feb 2013 A1
20130053005 Ramer et al. Feb 2013 A1
20130070928 Ellis et al. Mar 2013 A1
20130154822 Kumar et al. Jun 2013 A1
20130214925 Weiss Aug 2013 A1
20130267791 Halperin et al. Oct 2013 A1
20130272219 Singh et al. Oct 2013 A1
20130288639 Varsavsky Waisman-Diamond Oct 2013 A1
20130293368 Ottah et al. Nov 2013 A1
20130336174 Rubin et al. Dec 2013 A1
20140011470 D'Amato et al. Jan 2014 A1
20140022915 Caron et al. Jan 2014 A1
20140084165 Fadell et al. Mar 2014 A1
20140085093 Mittleman et al. Mar 2014 A1
20140101082 Matsuoka et al. Apr 2014 A1
20140120863 Ferguson et al. May 2014 A1
20140169274 Kweon et al. Jun 2014 A1
20140172953 Blanksteen Jun 2014 A1
20140222436 Binder et al. Aug 2014 A1
20140253326 Cho et al. Sep 2014 A1
20140266699 Poder et al. Sep 2014 A1
20140273912 Peh et al. Sep 2014 A1
20140273979 Van Os et al. Sep 2014 A1
20140306802 Hibbs, Jr. Oct 2014 A1
20140358666 Baghaie et al. Dec 2014 A1
20150065078 Mejia et al. Mar 2015 A1
20150071450 Boyden et al. Mar 2015 A1
20150082451 Ciancio-Bunch Mar 2015 A1
20150086001 Farrand et al. Mar 2015 A1
20150087280 Farrand et al. Mar 2015 A1
20150100167 Sloo et al. Apr 2015 A1
20150117624 Rosenshine Apr 2015 A1
20150138333 DeVaul et al. May 2015 A1
20150145693 Toriumi et al. May 2015 A1
20150177114 Kapoor et al. Jun 2015 A1
20150229770 Shuman et al. Aug 2015 A1
20150244873 Boyden et al. Aug 2015 A1
20150262435 Delong et al. Sep 2015 A1
20150281450 Shapiro et al. Oct 2015 A1
20150302725 Sager et al. Oct 2015 A1
20150334227 Whitten et al. Nov 2015 A1
20150339912 Farrand et al. Nov 2015 A1
20150379562 Spievak et al. Dec 2015 A1
20160012702 Hart et al. Jan 2016 A1
20160036751 Ban Feb 2016 A1
20160078750 King et al. Mar 2016 A1
20160117684 Khor et al. Apr 2016 A1
20160142758 Karp et al. May 2016 A1
20160173693 Spievak et al. Jun 2016 A1
20160248847 Saxena et al. Aug 2016 A1
20160277573 Farrand et al. Sep 2016 A1
20160300260 Cigich et al. Oct 2016 A1
20160323446 Farrand et al. Nov 2016 A1
20160330108 Gillon et al. Nov 2016 A1
20160330319 Farrand et al. Nov 2016 A1
20160330770 Lee et al. Nov 2016 A1
20160373372 Gillon et al. Dec 2016 A1
20170021802 Mims Jan 2017 A1
20170034044 Gillon et al. Feb 2017 A1
20170034062 Gillon et al. Feb 2017 A1
20170034081 Gillon et al. Feb 2017 A1
20170084164 Farrand et al. Mar 2017 A1
20170104875 Im et al. Apr 2017 A1
20170270569 Altberg et al. Sep 2017 A1
20170293301 Myslinski Oct 2017 A1
20180061213 Morehead Mar 2018 A1
20180075540 Bernard et al. Mar 2018 A1
20180152557 White et al. May 2018 A1
20180262441 Gillon et al. Sep 2018 A1
Foreign Referenced Citations (9)
Number Date Country
3050287 Aug 2016 EP
3146516 Mar 2017 EP
3167340 May 2017 EP
3295620 Mar 2018 EP
WO2015041738 Mar 2015 WO
WO2015179120 Nov 2015 WO
WO2016007244 Jan 2016 WO
WO2016182796 Nov 2016 WO
WO2018044657 Mar 2018 WO
Non-Patent Literature Citations (16)
Entry
“Office Action,” Canadian Patent Application No. 2949211, dated Aug. 16, 2017, 4 pages.
“Office Action,” Canadian Patent Application No. 2954351, dated Oct. 27, 2017, 3 pages.
International Search Report and “Written Opinion of the International Searching Authority,” Patent Cooperation Treaty Application No. PCT/US2017/048284, dated Nov. 8, 2017, 8 pages.
European Patent Application No. 14845956.3, “Extended European Search Report,” dated Feb. 16, 2017, 8 pages.
International Search Report and Written Opinion dated Nov. 7, 2014 for App. No. PCT/US2014/044945, filed Jun. 30, 2014. 12 pages.
International Search Report and Written Opinion dated Jul. 27, 2015 for App. No. PCT/US2015/029109, filed May 4, 2015, 12 pages.
International Search Report and Written Opinion dated Nov. 2, 2015 for App. No. PCT/US2015/034054, filed Jun. 3, 2015, 15 pages.
Life Alert. “Life Alerts Four Layers of Protection, First Layer of Protection: Protection at Home.” https://web.archive.org/web/20121127094247/http://www.lifealert.net/products/homeprotection.html. [retrieved Oct. 13, 2015], 4 pages.
International Search Report and Written Opinion dated Jun. 30, 2016 for App. No. PCT/US2016/030597, filed May 3, 2016, 12 pages.
“Extended European Search Report,” European Patent Application No. 15796148.3, dated Jan. 8, 2018, 8 pages.
“Office Action,” European Patent Application No. 14845956.3, dated Apr. 9, 2018, 4 pages.
“Extended European Search Report,” European Patent Application No. 15818258.4, dated Feb. 26, 2018, 8 pages.
“Notice of Allowance,” European Patent Application No. 14845956.3, dated Jul. 11, 2018, 7 pages.
Osterlund, Karl et al., “Communications Network Failure Detection and Remediation,” U.S. Appl. No. 16/011,479, filed Jun. 18, 2018, Specification, Claims, Abstract, and Drawings, 92 pages.
“Notice of Allowance”, Canadian Patent Application No. 2949211, dated Jul. 31, 2018, 1 page.
“Office Action,” Canadian Patent Application No. 2954351, dated Aug. 22, 2018, 4 pages.
Related Publications (1)
Number Date Country
20170034045 A1 Feb 2017 US
Continuations (1)
Number Date Country
Parent 14708132 May 2015 US
Child 15292038 US