TECHNICAL FIELD

[0002] This invention relates to packet networks, and more particularly to network devices.

BACKGROUND

[0003] This section contains a discussion of background. It summarizes telecommunications carrier network architectures that currently exist as legacy or that are currently under development. It also includes discussion of insights and observations made by the inventor about the prior art systems that are helpful to understanding the subsequently described invention but that were not necessarily appreciated by persons skilled in the art or disclosed in the prior art. Thus, the inclusion of these insights and observations in this background section should not be interpreted as an indication that such insights and observations were part of the prior art. After the background discussion, a new Edge Switched Network (ESN) architecture is introduced and it is described and compared to leading “Next Generation Network” alternatives. A Distributed Edge Switch (DES) makes possible the implementation of an ESN. In the OVERVIEW section that is found in the Detailed Description section, the design, operation and management of the DES are described within the architectural context provided by the ESN.

Next Generation Networking Approaches

[0004] In recent years, attempts to transform the legacy Public Switched Telephone Network (PSTN) to exploit the potential of the Internet has led to approaches that are loosely referred to as the Next Generation Network (NGN). It was believed that such approaches would lead to converged networks. Converged networks promise substantial cost savings and new service opportunities for telecommunications carriers (a.k.a. “carriers,” or “network service providers”). As a means to realize new data services, carriers have deployed overlay networks, which require overlay of new infrastructure onto existing legacy voice networks. In contrast, the converged approach of the NGN seeks to eliminate the need to have separate networks for different media. It exploits the principles of “openness” and leverages the standard protocols of IP networks to carry not only data but also other media such as voice and video.

The PSTN and AIN Principles

[0005] The NGN grew out of the PSTN, thus to understand its origins one must understand present day Advanced Intelligent Network (AIN) employed by PSTN carriers to provide advanced telephony services. The AIN was proposed as the solution to the carriers' needs to produce applications rapidly and independently of switch development efforts. Prior approaches had bundled services within switches, giving rise to long development times and inflexible service deployment. Service development and deployment was intimately tied to switch evolution and switch development cycles.

[0006] AIN proposed de-coupling service development and service logic from switches by building appropriate trigger points within the switch. Upon encountering a trigger detection point while processing a call, the switch, called the Service Switching Point (SSP), would trigger and send a query to a Service Control Point (SCP). FIG. 1 illustrates the elements of AIN. The SSP performs a query directed to an SCP. The SCP executes service logic that yields a result and that result is returned to the SSP that initiated the query. The SSP then continues with call processing.

[0007] As an example, when a subscriber dials an 800 number, an SSP detects that the call requires AIN service logic processing. The SSP directs a query to an SCP which in turn executes service logic that returns a valid dialing number to the SSP. The SSP then asks the Signaling System # 7 (SS# 7 ) network to set-up a call to that telephone number. SS# 7 sets up signaling and bearer paths necessary to support a call to that dialing number. The CENTRAL OFFICE SWITCH serving the called party applies a ringing tone to the called party's telephone. Once the called party answers, the call is established and both the parties can now have a telephone conversation.

[0008] FIG. 1 depicts the structure of the PSTN, including its support for AIN. The CENTRAL OFFICE SWITCH is decomposed into four distinct modules:

[0009] CALL PROCESSING

[0010] LINE

[0011] SIGNALING

[0012] TRUNK

[0013] The LINE module functions include detecting on-hook/off-hook, applying dial tone and ringing tone, collecting dialed digits, and communicating internally with the call-processing module. The CALL PROCESSING module analyzes the digits collected by the LINE module, and asks the SIGNALING module to perform appropriate actions. The SIGNALING module interfaces with the SS# 7 TRANSPORT NETWORK for the purpose of setting up a bearer channel between the calling and the called CENTRAL OFFICE SWITCHES. The TRUNK module transforms analog voice to a Time Division Multiplexed (TDM) format for transmission over PSTN trunks. The TRUNK module of the CENTRAL OFFICE SWITCH serving the called party converts the TDM trunk format back to analog for transmission over the local loop.

The Next Generation Networking Model

[0014] FIG. 2 illustrates the NGN approach. The NGN exhibits several similarities to the legacy PSTN. If one were to split apart the four modules that comprise the CENTRAL OFFICE SWITCH (see FIG. 1 ) into separate and distinct computing elements, the following components of a NGN network result:

[0015] MEDIA GATEWAY CONTROLLER

[0016] RESIDENTIAL GATEWAY

[0017] TRUNK GATEWAY

[0018] SIGNALING GATEWAY

[0019] To compare the functions of these elements to analogous functions in the CENTRAL OFFICE SWITCH, the MEDIA GATEWAY CONTROLLER (A.K.A. “softswitch,” or “call agent) performs the functions of the CALL PROCESSING module, the RESIDENTIAL GATEWAY (A.K.A. “customer gateway”) performs the functions of the LINE module and the TRUNK GATEWAY replaces the TRUNK module. Insofar as the RESIDENTIAL GATEWAY and TRUNK GATEWAY are both responsible for converting media provided in one type of network to the format required in another type of network, they are referred to generically as MEDIA GATEWAYS. With respect to support for network signaling functions, the SIGNALING GATEWAY in the NGN replaces the SIGNALING module in the CENTRAL OFFICE SWITCH. The similarities between the PSTN and NGN end here.

[0020] FIG. 2 shows a PACKET TRANSPORT NETWORK based on IP in OSI Layer 3 (the network layer) transported over ATM in OSI Layer 2 (the datalink layer). It interconnects all four NGN network elements. What were once major modules within a CENTRAL OFFICE SWITCH are now distributed network elements interconnected through a PACKET TRANSPORT NETWORK. The distributed nature of network elements in an NGN brings out one of the most striking differences between the PSTN and the NGN approaches. The theoretical advantages to be gained from this distribution include the following:

[0021] The MEDIA GATEWAY CONTROLLER may be implemented on a reliable, high-performance, fault-tolerant server that is IP-based and uses standard protocols to communicate with the gateways. Services can be implemented on separate platforms using open application programming interfaces (API), which should in theory lead to rapid development and deployment of services.

[0022] The MEDIA GATEWAYS can send media to each other over an IP-based PACKET TRANSPORT NETWORK using a protocol called Real Time Transport Protocol (RTP). The RTP protocol can be used to transmit not only voice but also data and video. The same IP transport and protocol can be used to carry multiple media types concurrently, a task that is difficult to accomplish with the circuit-switched PSTN network.

[0023] Unlike with the PSTN, where the signaling network is separate from the voice network, NGN utilizes the same PACKET TRANSPORT NETWORK to carry both signaling and media traffic.

[0024] Whereas communication between the four major modules is internal to the CENTRAL OFFICE SWITCH in the PSTN, the NGN uses a gateway control protocol for communication between the MEDIA GATEWAY CONTROLLER and the MEDIA GATEWAYS.

[0025] The most widely studied gateway control protocol is Media Gateway Control Protocol (MGCP) described by IETF RFC 3015 on Megaco Protocol Version 1.0. RFC 3015 is a common text with ITU-T Recommendation H.248, the most recent draft of which was developed as a close cooperation between the IETF Media Gateway Control Working Group (A.K.A. “MEGACO Working Group”) and ITU-T Study Group 16.

[0026] The precursor to MGCP was the Simple Gateway Control Protocol (SGCP) developed by Telcordia. At about the same time Telcordia was implementing SGCP, a company called Level 3 had developed a similar protocol called IP Device Control (IPDC). Rather than have two similar protocols develop and compete over time, Telcordia and Level 3 merged them into MGCP. MGCP was tailored to address a PSTN telephone and was not designed to handle data or multimedia. ITU-T Study Group 16 extended MGCP to support ISDN and multimedia, which led to Recommendation H.248. This body of work is today referred using the moniker MEGACO/H.248; it details a NGN reference architecture that provides an operational context for the description of the MGCP itself.

[0027] FIG. 2 depicts an NGN that is architecturally compatible with MEGACO/H.248. The following workflow sequence illustrates a typical call set-up procedure for the NGN depicted in FIG. 2 :

[0028] (1) A telephone goes off-hook. The RESIDENTIAL GATEWAY serving the telephone detects the off-hook event, applies dial tone, collects the dialed digits, and notifies the MEDIA GATEWAY CONTROLLER using MEGACO; The RESIDENTIAL GATEWAY also informs the MEDIA GATEWAY CONTROLLER that it is prepared to receive an RTP media stream at a certain port address, and further indicates the audio coding format it is able to support.

[0029] (2) The MEDIA GATEWAY CONTROLLER processes the digits and then must determine whether the called party telephone is connected to another RESIDENTIAL GATEWAY within the NGN or connected to a CENTRAL OFFICE SWITCH in the PSTN.

[0030] (3) Assuming the called party is connected to another RESIDENTIAL GATEWAY within the NGN, the MEDIA GATEWAY CONTROLLER queries the RESIDENTIAL GATEWAY serving the called party for an RTP port (and the audio coding format) at which it would prefer to receive an RTP stream from the calling party RESIDENTIAL GATEWAY.

[0031] (4) The called party RESIDENTIAL GATEWAY responds with the port at which it can receive an RTP audio stream from the calling party and the audio coding format it is able to support.

[0032] (5) The called party RESIDENTIAL GATEWAY applies a ringing tone to the called party's telephone.

[0033] (6) The MEDIA GATEWAY CONTROLLER informs the calling RESIDENTIAL GATEWAY of the audio coding format supported by the called RESIDENTIAL GATEWAY and the port at which it is expecting to receive an RTP stream.

[0034] (7) Following more exchanges of information, both the calling and called party RESIDENTIAL GATEWAYS know the port addresses and supported audio coding formats necessary for them to send and receive RTP streams (containing encoded audio) to/from each other.

[0035] (8) Once the called party answers the telephone, two-way communication using RTP streams is established.

Implications of NGN Deployment

[0036] There are several significant implications that result from delivering network services to subscribers through an NGN rather than the PSTN. Several of them are summarized in the points below:

[0037] Unlike the PSTN, which has a signaling network that is separate from the TDM network for establishing bearer paths, the NGN network carries both signaling and media streams over the same IP network, thereby achieving a certain measure of convergence.

[0038] Whereas the PSTN requires separate overlay networks and protocols for other media beyond voice, the NGN utilizes the same IP network and protocols for all media communications (i.e. voice, data, video).

[0039] While the PSTN carries voice media over dedicated circuit switched connections, NGN carries media streams in RTP packets that are treated in the same manner as any other IP packets, using the “best effort” paradigm the Internet employs for routing packets. This means that packets can encounter delays; they can be dropped due to congestion control mechanisms that throttle packets at the source or at the ingress to the network. Hence, the bare public Internet does not offer quality of service. Consequently, an NGN implementation requires the creation of a special-purpose IP network to support network quality of service (QoS). In contrast, the PSTN is capable of guaranteeing QoS service for point-to-point connections transporting voice or data.

[0040] The NGN interworks with the PSTN via TRUNK GATEWAYS and SIGNALING GATEWAYS. Thus, while the end-to-end connection between two NGN subscribers would occur entirely within the PACKET TRANSPORT NETWORK, the end-to-end connection between and NGN subscriber and a PSTN subscriber would occur in both the NGN and the PSTN, using a TRUNK GATEWAY and a SIGNALING GATEWAY to carry bearer channel content and network signaling information, respectively, between the two subscribers participating in the call.

[0041] Third-party applications can be offered via an open applications programming interface (API) offered by the MEDIA GATEWAY CONTROLLER. Some standards for Open APIs include PARLAY, JAIN, XML, or SOAP. It is beyond the scope of this discussion to provide definitions for these APIs or to elaborate on them beyond presenting their monikers. Let it simply be said that the thrust of these APIs was originally an effort to make AIN infrastructure in the PSTN accessible to third-party application providers so that they could offer new and innovative network services. With the advent of the NGN, it was envisioned that the same set of APIs would be suitable to provide third-party NGN applications with the ability to access similar features by interfacing with the MEDIA GATEWAY CONTROLLER.

[0042] The NGN makes it possible for a carrier to provide plain old telephone service (POTS) over a PACKET TRANSPORT NETWORK by using a MEDIA GATEWAY CONTROLLER and a RESIDENTIAL GATEWAY rather than a CENTRAL OFFICE SWITCH. As already explained, the RESIDENTIAL GATEWAY takes on the role of the LINE module of the CENTRAL OFFICE SWITCH; therefore, there are no NGN requirements to change the telephone itself.

A Victim of Failed Economics

[0043] Though the NGN is today restricted in its applicability to voice communications, it was originally the hope of both carriers and vendors that voice-over-IP (VoIP) would serve to bootstrap the NGN and spawn off a new era of converged networks that would cater to voice, video and data communications. Convergence promised to transform the PSTN into a general purpose “multi-service network” capable of simultaneously delivering voice, video and data services through a common PACKET TRANSPORT NETWORK that supports QoS. Thus far this expectation has not materialized due to the carriers' reluctance to widely deploy a network based on the NGN architecture. At the current time, many carriers perceive the NGN architecture unsuitable to meet their forward-looking objectives to decrease network operating costs while at the same time increase network service revenues. Ultimately the NGN became a victim of failed economics that resulted from its inordinate complexity and insufficient support for new services.

Complexity Confounds NGN Deployment

[0044] The inordinate complexity of the NGN is to a large extent due to overreliance on centralized control elements for network service delivery. While its many network elements may be physically distributed, the NGN architecture's logical centralization mimics the functionally of the “mainframe-oriented” PSTN. The NGN architecture has more recently been altered from its original design to model the Internet, relying upon a “horizontal integration” of specialized, cooperating network elements. Many of these network elements are not shown in FIG. 2 , but are necessary for NGN implementation (e.g. feature servers, media servers, integrated access device controllers, policy servers, domain naming servers, SIP proxy servers, TRIP servers, subscriber directory servers). Very much unlike the internet, virtually all NGN network elements require some degree of centralized control by, or interaction with, the MEDIA GATEWAY CONTROLLER according to specialized protocols. All of these protocols communicate through (i.e. generate traffic on) the carrier's PACKET TRANSPORT NETWORK.

[0045] To support its centralized service delivery model, the “vertically integrated” PSTN was based on a hardware scaling model in which the majority of software processes communicated directly with each other inside purpose-built hardware computing modules. These computing modules physically plugged into each other to create large, distributed mainframe computers such as the CENTRAL OFFICE SWITCH. The more horizontally integrated NGN is based on a software scaling model that for all intents and purposes remains as operationally centralized as the PSTN, if not more so in some instances where control over a very large number of subscribers (potentially millions) may be aggregated into a regional office. Adherents of the NGN architecture maintain that such a high degree of centralization offers cost benefits; however the cost benefits of centralization are to a large measure offset by fault vulnerability and the costs associated with ensuring system redundancy. Generally speaking, if something in a network does anything for thousands of subscribers at the same time, not only does the carrier need two of them, but also the ability to automatically fail over from one to the other without dramatically interrupting service delivery. Implementing this level of functionality for centralized components is challenging and often prohibitively expensive.

[0046] As depicted in FIG. 2 , the physically distributed, highly-decomposed NGN architecture relies upon a an “orchestra” 0 of interdependent software services running on distributed network elements; these software services, each according to its unique role, communicate in one-to-one, many-to-one, or one-to-many relationships with other interdependent software services through the PACKET TRANSPORT NETWORK, each using specialized protocols.

[0047] Due to physical limitations on how many MEDIA GATEWAYS can be controlled by a single MEDIA GATEWAY CONTROLLER, the NGN must be partitioned into control zones. Local device-level signaling performed by the MEDIA GATEWAY CONTROLLER within its control zone must be somehow synchronized with end-to-end network signaling that would be necessary for a call to span more than a single zone. The result is a two-tiered signaling architecture—a concession to the inelegant NGN scaling model and its inherent requirement for network partitioning. Network signaling protocols such as Session Initiation Protocol (SIP) are used between control zones for end-to-end network signaling, whereas MEGACO is used closer to the endpoint for local MEDIA GATEWAY control.

[0048] Among other things, the two-tiered signaling model complicates the integration of APPLICATION SERVERS (and potentially PBXs) that typically require more signaling information than can be conveyed by MEGACO (e.g. calling and called party dialing numbers). As a result, network signaling using SIP must be extended directly to the APPLICATION SERVER as if it were another MEDIA GATEWAY CONTROLLER i.e. another “control zone.” Thus, for the NGN to enable network-based enhanced services such as voice mail or group conferencing, it must interface APPLICATION SERVERS using a different method than the way it interfaces telephones. From an operational perspective, the two-tiered signaling model means that the MEDIA GATEWAY CONTROLLER becomes a lynch pin, and must now actively mediate all telephone access to the APPLICATION SERVERS.

[0049] In the NGN, subscriber telephones are connected through RESIDENTIAL GATEWAYS and controlled by the MEDIA GATEWAY CONTROLLER using MEGACO. This complexity has further implications in terms of complicating overall network design, particularly with respect to the scaling of participating network elements. Thus, as a consequence of its inordinate complexity, the NGN architecture brings with it a number of very significant implementation considerations that may be summarized as follows:

[0050] Potential poor performance resulting from the high processing overhead: network functionality is highly decomposed into distributed network elements that must communicate through the network itself using various protocols;

[0051] Numerous indeterminate scaling relationships that introduce a proportionally larger number of potential bottlenecks;

[0052] Troubleshooting procedures that must isolate and resolve problems that appear to reside in more than one place do to protocol incompatibilities;

[0053] Software integration requirements that are difficult for most carriers to support.

[0054] It is the conclusion of this analysis that the NGN architecture as represented in FIG. 2 has too many moving parts to operate efficiently. Attempts to remedy these limitations ultimately translate into implementation cost for the carrier attempting to deploy an NGN.

Insufficient Support For New Services Confounds NGN Deployment

[0055] The NGN architecture suffers from insufficient support for new services. It largely replicates the telephone-oriented feature set of today's PSTN. Due to the centralized control model of the NGN, support for new network services is dependent upon the ability of the MEDIA GATEWAY CONTROLLER and APPLICATION SERVERS to provide the features that comprise a network service. Much like with the PSTN, feature delivery by a centralized controlling entity is limited by the carrier's ability (and willingness) to modify the controlling entity to provide new services. Notwithstanding the NGN vision of third-party applications and new services supported through MEDIA GATEWAY CONTROLLER APIs, as a practical matter it is a tenuous proposition to modify access to it, or add to its service load once it has been optimized to deliver a particular portfolio of services.

[0056] Beyond risks related to destabilizing the core of the network by providing API access to the MEDIA GATEWAY CONTROLLER, the generic concept of using APIs to integrate application services came into question some time after the inception of the NGN and its API-based strategy. In actual practice—“actual practice” being a function of industry consensus derived from years of internet experience—third-party applications offered through the NGN are probably better integrated using standard IP-based IETF protocols such as SIP and Hypertext Transfer Protocol. APPLICATION SERVER integration into the PACKET TRANSPORT NETWORK using internet-style protocols (based on message passing) has proven far more flexible and cost-effective than integrations based on APIs. APIs tend to be highly vendor-specific, programming language-specific, and, since they are based fundamentally on function calls rather than message sets, tend to be less tolerant of partial implementation.

[0057] Notwithstanding the foregoing, it should be kept in mind that network signaling protocols like SIP are not compatible with the device-oriented MEGACO protocol used to control telephones connected to RESIDENTIAL GATEWAYS. Thus, as pointed out earlier in the discussion, the two-tiered signaling model of the NGN puts the MEDIA GATEWAY CONTROLLER into a mediation role, performing an imperfect translation between its use of MEGACO to control service delivery to telephones and its use of SIP as the means to access application services.

[0058] Interactive calling services were originally envisioned that would provide the NGN subscriber with the ability to select or customize call processing logic, perhaps even to enable interoperability between network features and application programs running on the subscriber's personal computer (e.g. active browser sessions, instant messaging clients) or to access subscriber-specific data objects (e.g. contact lists, call logs, content subscriptions). Implementation of these types of interactive calling services using only AIN-style APIs was eventually perceived as largely impractical in the NGN because the MEDIA GATEWAY CONTROLLER (supporting the APIs) would be required to access, manage, and execute unique, complex service logic for very large number of subscribers at the same time. The following points illustrate other significant limitations of the NGN with respect to supporting new services:

[0059] In the NGN, the MEDIA GATEWAY CONTROLLER delivers telephone features by remotely controlling the RESIDENTIAL GATEWAY. It can only deliver features through a RESIDENTIAL GATEWAY whose feature set it fully understands according to the MEGAGO standard. This factor imposes substantial constraints on the variety of network services the NGN can deliver because it is impractical or unfeasible to control an endpoint feature set that extends beyond that anticipated by MEGACO.

[0060] Calling services that perform call control operations require a full knowledge of subscriber Class of Service parameters and service delivery preferences. This information governs not only the subscriber's ability to invoke the calling service in the first place, but the unique behavior of the service when invoked by that particular subscriber. Most of the information that interactive calling services (e.g. call log functions, programmable call-blocking and call-forwarding) require is buried somewhere deep inside the NGN infrastructure in much the same way that it was buried inside the CENTRAL OFFICE SWITCH in the PSTN. This factor imposes substantial constraints on the variety of network services the NGN can deliver because call log entries and related subscriber-specific network usage data are largely unavailable for real-time access by third-party applications.

[0061] RESIDENTIAL GATEWAYS are unintelligent in the sense that they require the MEDIA GATEWAY CONTROLLER to mediate all network signaling functions on their behalf. They cannot determine the broader network signaling context of the calling operations in which they participate. They are incapable of independently executing service logic that involves network signaling operations (e.g call redirection, multipoint call control, call supervision, multiple line appearances, etc.) without centralized participation by the MEDIA GATEWAY CONTROLLER. These factors impose substantial constraints on the variety of network services the NGN can deliver because each new service must be tightly integrated with the MEDIA GATEWAY CONTROLLER in order to perform call control operations.

[0062] To work around these constraints, recent approaches to offering new services in the NGN have put an application between the RESIDENTIAL GATEWAY and the MEDIA GATEWAY CONTROLLER. The application is responsible for controlling the subscriber's telephones, giving them access to various new features. These approaches support: (a) a variety of telephone types not supported by standard MEGACO; (b) better access to call log records and related subscriber-specific network usage data; and (c) the ability to execute user-configurable service logic not supported by the MEDIA GATEWAY CONTROLLER.

[0063] As an example of this approach, companies such as Cisco, Broadsoft, LongBoard, and Sylantro have built application systems that provide optimized combinations of business telephone services that include PBX and Centrex features. While some of these solutions are designed for enterprise deployment, those intended for carrier deployment are often referred to using the moniker “IP Centrex.” IP Centrex solutions provide calling services and telephone features using various brands of office telephones and web browser-based graphical user interfaces. Generically, IP Centrex solutions equate to a network-based software PBX application that replaces much of the functionality of the MEDIATE GATEWAY CONTROLLER.

[0064] IP Centrex solutions are often referred to in the industry as “point solutions.” Point solutions enable the carrier to provide a very particular set of new services for isolated populations of subscribers. They are a work-around bourne out of necessity and introduce additional “non-standard” intermediary network elements into the NGN. Adding new network elements of this type brings with it significant scaling implications associated with carrier deployment of a service that cannot scale as the network itself scales. Point solutions are operationally unfeasible for carriers serving tens of millions of subscribers because the feature set of the point solution cannot be managed as a standard network feature set that may be enabled or disabled for any subscriber at will. If such a service became popular, the carrier would have to replicate many instances of the system—potentially thousands of them—each to serve a certain critical mass of subscribers, and then to manage these systems as independent islands of service delivery capability.

[0065] As summarized below, point solutions bring with them their own unique set of carrier deployment challenges and at the same time do not resolve the general limitations of the NGN with respect to supporting new services:

[0066] Point solutions do not in a general sense enable the NGN to control a telephone feature set (or other endpoint device feature set) that extends beyond that anticipated by MEGACO, but instead supports selected vendor telephones in a way that suits their own specific purposes.

[0067] Point solutions do not in a general sense make call log records and related subscriber-specific network usage data available for real-time access by a third-party applications, but instead simply store it internally for their own use.

[0068] Point solutions do not in a general sense make it possible for third-party applications to perform call control operations, but instead implement call control operations for their own specific purposes.

NGN Support For Multi-Service Delivery

[0069] The NGN architecture leaves to future consideration features sets that extend beyond traditional PSTN voice services. It assumes central office (or equivalent) deployment for most network elements and that the RESIDENTIAL GATEWAY is providing telephone service over a general-purpose PACKET TRANSPORT NETWORK that supports QoS. Video and data services are not addressed directly by the NGN, and it is assumed that other network elements and related infrastructure components will provide these services independently.

[0070] The above assumptions do not anticipate that the subscriber purchasing voice services is also likely to purchase data and video services from the same carrier. When the carrier's primary connection to the subscriber premise is through a broadband access network, it quickly become impractical to install a separate physical connection or independent solution for each type of media service offered to that subscriber. Much of the motivation behind the transition to a converged network is based on the notion that multiple services—voice, video, and data services—can be offered to a network subscriber through a single IP data path to the premise. The converged vision extends to enabling carriers to combine several media types into a comprehensive network services offering.

[0071] This type of multi-service delivery requires QoS arbitration at the subscriber premise so as to ensure QoS for all voice, video, and data terminal devices (i.e. telephones, televisions, PCs) installed there; all of these terminal devices may be operating at the same time sharing the same IP data path. Many potential new services anticipate providing value to subscribers because of their ability to support multiple media types at the same time, potentially integrating two services that support different media types in a way that makes each more useful. In addition, voice, video and data terminal devices installed at the subscriber premise often support different control interfaces that must be normalized to network signaling and device control conventions that would enable them to interact with network-based APPLICATION SERVERS in a consistent fashion.

[0072] Equipment vendors have responded to requirements to enable NGN multi-service delivery through a single IP data path to the subscriber premise by creating an integrated access device (IAD). The IAD began life as specialized version of a RESIDENTIAL GATEWAY, designed as a means to enable subscribers to connect voice and data terminals at the premise in such fashion as they may share a common IP data path to the carrier's PACKET TRANSPORT NETWORK. The IAD marketplace today offers the carriers a bewildering assortment of devices, targeting optimal combinations of cost effectiveness and/or feature richness.

[0073] Some IADs support voice-over-IP and QoS arbitration features whereas others attempt to obviate total reliance on remote IAD control by a MEDIA GATEWAY CONTROLLER (using MEGAGO) by implementing selected POTS telephone features and SIP network signaling within the IAD. Some IADs used by the cable industry do not support VoIP in the NGN sense of it, but instead provide for “voice-over-broadband.” The term voice-over-broadband refers to a family of proprietary access network designs, the most common of which is that used by cable companies that transport voice, as well as data and video, on distinct broadband channels created through frequency division multiplexing (FDM). In this type of voice-over-broadband network, voice and data flows are split at the central office (or central office equivalent), with the voice path connecting to a CENTRAL OFFICE SWITCH (usually through a GR 303 packet interface). IADs of this type are excepted from this discussion because they do not support the converged “end-to-end IP” vision of the NGN and are fundamentally incompatible with it.

[0074] NGN voice services offered through an IAD using VoIP are virtually identical to voice services offered directly through a POTS line connected to a CENTRAL OFFICE SWITCH. Typically, the IAD is used to connect telephones and computers to a broadband data service provided to the premise. Through the gateway facilities of the IAD, voice and data are transported as distinct packet flows over a common IP data path that is contiguous (from an IP connectivity standpoint) with the PACKET TRANSPORT NETWORK. In the NGN, the feature set of the CENTRAL OFFICE SWITCH is emulated by the MEDIA GATEWAY CONTROLLER in concert with a number of other network elements such as a “feature server.” Conceptually, in the NGN the IAD functions exactly as any other RESIDENTIAL GATEWAY.

[0075] Unable to deliver traditional PSTN network services independently, and devoid of the ability to enable compelling new service capabilities, the value proposition of the IAD lies in its ability to enable the subscriber to use one physical line (e.g. DSL line, cable, T 1 ) for both voice and data at the same time. In summary, the cost of the IAD must be compared to the cost of simply installing separate voice and data lines to the premise.

[0076] After substantial field experience, technical staff at two major United States Local Exchange Carriers recently concluded that the cost for them to deploy network services using an IAD is greater than or equal to the cost to deploy separate voice and data lines to the premise, except in rare cases where it would be exceptionally expensive to bring in an additional line. Despite wide availability several for years, the limited deployment of IADs further suggests that the NGN has been a victim of failed economics. From a pure technical perspective, an IAD may be an appropriate “edge device” form-factor to address MEGACO requirements for multi-service delivery to the subscriber premise. This observation does not remedy the underlying problem that its cost to deploy is perceived as more than can be justified by the modest functionality it enables.

SUMMARY

An Edge Switched Network Architecture

[0077] An Edge Switched Network (ESN) architecture is introduced as an innovation whose implementation is dependent upon the Distributed Edge Switch (the “invention” that is the subject of this disclosure). The general operating principles of the ESN are described below as a pretext to a detailed description of the Distributed Edge Switch (DES) found in the OVERVIEW section. It will be shown that the ESN resolves many of limitations inherent to the NGN.

[0078] FIG. 3 depicts an ESN architecture principally comprised of “connectivity elements.” A connectivity element is a particular type of network element that is capable of participating in call sessions using SIP network signaling and RTP bearer transmission. Communities of connectivity elements communicate in a peer-to-peer fashion without necessarily requiring assistance from the network beyond IP connectivity. The three connectivity element types defined for the ESN are as follows:

[0079] EDGE SWITCH

[0080] APPLICATION SERVER

[0081] PSTN GATEWAY

[0082] All three connectivity elements share a similar network interface design that combines support for SIP network signaling, RTP bearer transport, media encoding/decoding, and event-driven call processing into a single intelligent endpoint device. From a conceptual standpoint, each connectivity element collapses functionality from each major NGN network element into a self-contained whole capable of “intelligent participation” in call sessions. Intelligent participation refers to the ability of a connectivity element to operate both as SIP network signaling endpoint and as a call control agent capable complex call control operations. Complex call control operations might involve supervising call sessions that contain multiple call legs extending to other connectivity elements. Connectivity elements may leverage network-based SIP proxy servers to support these and other complex operations.

Role of the Edge Switch in the ESN

[0083] The EDGE SWITCH is an ESN connectivity element whose principal function is to support the delivery of voice, video (multimedia) and data services—multi-service delivery—to the subscriber premise through a shared IP data path. It aggregates several functions together into a single, cost-effective device that is deployed by the carrier as a premise-based network element.

[0084] FIG. 3 shows that the EDGE SWITCH functions as a broadband access network termination device (e.g. DSL modem, cable modem, T 1 terminator, passive optical terminator) at the subscriber premise, providing an IP data path from the premise to the PACKET TRANSPORT NETWORK. It also provides a means by which voice, video and data terminals at the subscriber premise may connect to other network endpoints in the PACKET TRANSPORT NETWORK, each creating connections through a shared, routed IP data interface.

[0085] Ultimately, all subscriber terminals plugged into the EDGE SWITCH communicate with the PACKET TRANSPORT NETWORK through QoS routing capabilities built into the EDGE SWITCH. EDGE SWITCH routing capabilities enable QoS arbitration at the exact point where subscriber terminals interface the broadband access network. Video streaming services deployed within the network are made accessible to SIP media streaming devices connected to the EDGE SWITCH (such as SIP-enabled set-top boxes). Data transmission capacity not used for voice telephone communications or media streaming is made accessible to data terminals for data communications. The EDGE SWITCH operates as a MEDIA GATEWAY to the extent that it is able to present POTS or other types of non-SIP telephones (connected through its LINE interface) to the network as SIP network signaling endpoints. The EDGE SWITCH provides necessary terminal adaptation as necessary for the conversion of device signaling and bearer channel content at the LINE interface to/from SIP network signaling and RTP voice transmission conventions required by the ESN.

[0086] The EDGE SWITCH executes locally stored call processing applications in response to detecting network trigger events. In this way, voice telephone features and related calling services are provided by the EDGE SWITCH to the subscriber through legacy POTS and/or IP telephones, without the participation of centralized network control elements.

[0087] In order to perform in the capacities described above, the EDGE SWITCH must operate as a general computing device able to execute complex software programs and store relatively large amounts of information. More specifically, the EDGE SWITCH contains the following:

[0088] Sufficient computing capacity, memory, and operating system functionality necessary to support application-level program development and application program execution; particularly the execution of call processing applications;

[0089] Sufficient storage capacity to hold an operating event history of a year or more; operating events include configuration changes and all potentially billable subscriber access to calling services (e.g. call log records);

[0090] Sufficient storage capacity to hold all call processing application executable code needed to support network service delivery according to the subscriber's Class of Service;

[0091] Sufficient storage capacity to hold local call routes and network addressing information needed to support network service delivery (via call processing applications) for all subscribers served by the EDGE SWITCH;

[0092] Sufficient storage capacity to hold subscriber Class of Service parameters and service delivery preferences needed to govern the subscriber's ability to invoke a particular calling service and the unique behavior of the service when actually invoked.

[0093] System software to support a SIP network signaling protocol stack that can be programmed to selectively expose trigger points in a call that automatically invoke service logic (i.e. call processing applications).

[0094] System software to support centralized service provisioning, device management, and software upgrades by a remote system management platform

[0095] System software to support the full complement of QoS arbitration, including traffic classification, packet labeling, packet scheduling, and admission control based on subscriber Class of Service.

[0096] System software to support real-time remote monitoring of network service delivery, with active reporting of status to a remote system management platform.

[0097] System software required to meter network service delivery by generating call log records and to store them in a database internal to the EDGE SWITCH.

[0098] System software required to normalize vendor-specific terminal device interfaces to comply with network signaling and device control conventions that would enable them to interact with network-based APPLICATION SERVERS in a consistent fashion.

[0099] Secure data exchange interfaces that make EDGE SWITCH features and all information stored within its internal databases accessible to remote database clients, network management systems, and third-party applications.

Role of the Application Server in the ESN

[0100] The APPLICATION SERVER is an ESN connectivity element whose principal function is to support the delivery of network services to other ESN connectivity elements. As is common to all ESN connectivity elements, the APPLICATION SERVER is capable of intelligent participation in call sessions. It can execute internally stored call processing applications (service logic) in response to network signaling events and related trigger points in a call. An example of signaling events that would trigger service logic execution include an attempt by a SIP signaling endpoint to connect to the APPLICATION SERVER or disconnect from it once connected. Trigger points in a call might include events detected while the SIP call session is in progress, such as mid-session control messages or certain call control operations.

[0101] In most scenarios, network services or features supported by an APPLICATION SERVER are rendered directly to SIP network signaling endpoints that connect to it. For reasons of security and protocol compatibility, the APPLICATION SERVER may implement secure connection policies that prohibit access to SIP network signaling endpoints that are not directly managed or mediated by another ESN connectivity element. For example, a PC-based SIP client attempting to connect to the APPLICATION SERVER through the public internet may be prohibited from doing so; however, a PC-based SIP client attempting to connect to the APPLICATION SERVER through an EDGE SWITCH will have its SIP signaling mediated by that EDGE SWITCH—perhaps encrypted according to an internal carrier network standard—and as a result may be allowed to connect to the APPLICATION SERVER in this way.

[0102] Upon detecting a SIP call session initiation, the APPLICATION SERVER examines SIP signaling information and compares it with what it knows internally about the calling party so that it may automatically determine the feature, function, or service that it should render to the calling party. For example, if the calling party is a SIP network signaling endpoint (SIP User Agent) used by an EDGE SWITCH to represent a POTS telephone at the subscriber premise, the APPLICATION SERVER will receive the dialing number of the calling party (i.e. the dialing number assigned to the POTS telephone originating the call). It may then use this dialing number to access an internal database for the purpose of retrieving the Class of Service parameters associated with this dialing number. Class of Service parameters will inform the APPLICATION SERVER as to whether or not it should render its service to the calling party.

[0103] Aside from the number of simultaneous SIP call sessions it can potentially support—a function of its hardware form-factor—there is a fundamental difference between the APPLICATION SERVER and the EDGE SWITCH: whereas the APPLICATION SERVER renders network services and features to a calling party, the EDGE SWITCH renders network services and features to terminal devices plugged into it at the subscriber premise.

[0104] In rendering network services and features to a calling party, the APPLICATION SERVER exploits the capabilities of various system resources. Call processing applications executing on the APPLICATION SERVER may perform database queries, media store-and-forward operations, support group conferencing, convert text to speech, recognize voice commands, or any one of a number of operations that might be beyond the scope of what an EDGE SWITCH could perform without assistance from the network. By simply connecting to an APPLICATION SERVER, an EDGE SWITCH or PSTN GATEWAY may request and receive the intelligent participation of the APPLICATION SERVER when they require such assistance.

Role of the PSTN Gateway in the ESN

[0105] The PSTN GATEWAY is an ESN connectivity element whose principal function is to (a) make it possible for the EDGE SWITCH to connect to PSTN endpoints using SIP network signaling and (b) to make it possible for PSTN endpoints to connect to the EDGE SWITCH using PSTN network signaling. The PSTN GATEWAY combines the functions of the NGN architecture's SIGNALING GATEWAY, TRUNK GATEWAY, and MEDIA GATEWAY CONTROLLER so as to enable SIP call sessions connecting to it to be bridged to PSTN endpoints. It provides necessary signaling gateway functions as required to interface the PSTN using SS# 7 protocols. It also provides necessary media gateway functions to convert bearer channel encoding formats at the TRUNK interface to/from SIP and RTP voice transmission conventions required by the ESN.

[0106] A connection attempt that originates in the ESN and that is intended to ultimately connect to a PSTN endpoint, will be directed to a SIP network signaling endpoint on a PSTN GATEWAY. The PSTN GATEWAY will initiate essentially the same workflow sequence used by the APPLICATION SERVER to execute internally stored call processing applications. Consistent with its specialized role in the ESN, the PSTN GATEWAY will execute a call processing application that will connect the incoming SIP call session through to the specified PSTN endpoint. Thus, an incoming SIP call from the ESN to the PSTN GATEWAY will initiate a corresponding PSTN call set-up to a PSTN endpoint through the TRUNK interface. In the reverse direction, an incoming PSTN call through the TRUNK interface will result in a SIP call set-up to a SIP network signaling endpoint in the PACKET TRANSPORT NETWORK.

Architectural Comparison of ESN to NGN

[0107] The ESN is substantively different from the NGN in a number of significant ways, and as a result of these differences, the ESN remedies certain architectural limitations inherent to the NGN as set forth in the foregoing sections. By showing how specific limitations of the NGN are resolved by the ESN, the summary below affords an opportunity to highlight important capabilities inherent to the ESN architecture within a relevant context:

[0108] (1) The potential poor performance of the NGN resulting from high processing overhead for distributed elements communicating through the network (and attendant scaling problems related thereto) is resolved by the following:

[0109] Eliminating the MEDIATE GATEWAY CONTROLLER function entirely, and instead distributing call processing capability throughout the network by embedding it in intelligent endpoint devices;

[0110] Feature-oriented network service delivery to subscribers through terminals at the premise is performed by dedicated computing resources physically located on the subscriber premise (i.e. by the EDGE SWITCH);

[0111] To the extent that the above method of feature delivery does not require assistance from the network for most call processing functions, feature responsiveness is perceived by ESN subscribers to be essentially instantaneous, regardless of the number of simultaneous ESN network users;

[0112] As a consequence of eliminating the MEDIA GATEWAY CONTROLLER function entirely, so too is the gateway control layer eliminated, effectively flattening the two-tiered NGN network signaling model into a normalized SIP network signaling model. According to the normalized SIP network signaling model, voice and multimedia connections are established peer-to-peer using the same method;

[0113] As a result of flattening the two-tiered NGN network signaling model into a normalized SIP network signaling model, overall ESN system performance with respect to APPLICATION SERVER access by EDGE SWITCHES and PSTN GATEWAYS is dramatically enhanced. The delivery of network-based features provided by APPLICATION SERVERS in the ESN is perceive by subscribers to be essentially instantaneous and relatively unaffected by the number of simultaneous ESN network users.

[0114] (2) The NGN's large number of potential bottlenecks that are introduced as a result of its numerous indeterminate scaling relationships are resolved by the following:

[0115] Reducing the number of network elements that are needed to participate in network service delivery;

[0116] Embedding feature delivery and service metering functions into the network access device (EDGE SWITCH or PSTN GATEWAY) so as to eliminate requirements for the centralized network elements to retain information about the state of any given call.

[0117] (3) Troubleshooting procedures for the NGN must isolate and resolve problems that appear to reside in more than one place because of protocol incompatiblities. This issue is resolved in the ESN by the following:

[0118] Reducing the total number of protocols;

[0119] Reducing the total number of network elements.

[0120] Managing all connectivity elements as populations of like elements, each of which supports more or less identical provisioning, device management, diagnostic, and event reporting mechanisms, and each using the same interface protocols to support similar tasks.

[0121] (4) Software integration requirements for the NGN are difficult for most carriers to implement and support. This issue is resolved in the ESN by the following:

[0122] Supporting a hardware scaling model in which ESN service delivery capability is built up in a predictable, linear fashion by replicating connectivity elements;

[0123] Embedding most subscriber-oriented features into a very low-cost device (EDGE SWITCH) that is physically replaced if an error condition is detected rather than repaired; the replacement unit is then automatically detected and re-synchronized with a system management platform so that identical network service capabilities are restored to the subscriber;

[0124] Requiring relatively few centralized software processes to support feature-oriented network service delivery, as compared to the NGN;

[0125] Utilizing SIP-based access to service logic running within APPLICATION SERVERS for advanced feature support—a method that sharply contrasts with NGN support for API access to call processing capabilities within the MEDIA GATEWAY CONTROLLER.

[0126] (5) The economic model for the NGN that has not proved compelling to carriers largely due to high implementation costs resulting from its inordinate complexity. The relative simplicity of the ESN translates into a lower relative cost for greater network service delivery capability, thereby increasing the likelihood that its economic model would be compelling enough to motivate carrier implementation. Some of the principal reasons for its simplicity relative to the NGN include the following:

[0127] The ESN is capable of delivering traditional PSTN network services and new multi-service capabilities through a common means with little or no reliance on feature-controlling infrastructure in the central office;

[0128] The ESN employs a hardware scaling model that uses primarily mass produced, low-cost EDGE SWITCHES for most of its subscriber-oriented service delivery;

[0129] The ESN requires dramatically less effort to test compared to the NGN, since validating the feature set of a single EDGE SWITCH for a certain number of concurrent sessions confers validation of the ability to support any multiple of that certain number of concurrent sessions by deploying a proportionate multiple of additional EDGE SWITCHES;

[0130] The ESN enjoys very low implementation costs due to the fact that its network integration is based on relatively few protocols other than SIP. The MEGACO protocol stack is eliminated from the model, along with all attendant requirements for licensing and interoperability testing between MEGACO-compliant network elements.

[0131] As a consequence of these factors, overall system cost for the ESN on a per-user basis has been calculated to be less expensive than PSTN technology to provide an equivalent feature. Overall system cost for the ESN has been estimated to be less expensive than the NGN to provide an equivalent feature.

[0132] In consideration of the above cost estimates, it should be noted that indeterminate scaling relationships in the NGN, and the lack of deployed NGN networks that could be used for direct comparison, are factors that together confound attempts to quantify the true implementation cost of an actual NGN deployment. A theoretical calculation of cost-per-subscriber (i.e. an estimate) in the NGN might not necessarily reflect actual feature delivery capacity because of unanticipated effects that are likely to result from its highly decomposed architecture.

Support for New Services in the ESN

[0133] Support for new services by the ESN is made possible because of several capabilities that are inherent to its architecture. Some of these capabilities are described as follows:

[0134] The ESN supports voice, video and data-oriented network services through a common (i.e. shared) IP data path, providing QoS arbitration at the premise as is required to support multi-service delivery; thus, new services can be offered for each type of media, or new services can combine features that involve more than one type of media into a single multimedia service. As an example, a feature could be created to lower the volume of the television if someone answered the telephone;

[0135] Feature delivery by the EDGE SWITCH is remotely programmable by the carrier; software loads can be uploaded into the EDGE SWITCH to introduce new features over time without network infrastructure changes;

[0136] The ESN subscriber may interact with the EDGE SWITCH to select features and program them to behave according to subscriber-specific parameters, potentially to interoperate with a variety of third-party applications, application programs running on the subscriber's PC, or to securely access data objects stored in network servers or on the subscriber's PC. As an example, an application could use instant messaging to inform the end user as to the identity of a calling party.

[0137] Most ESN network intelligence is located within the EDGE SWITCH itself. A large part of this “network intelligence” includes the EDGE SWITCH'S ability to internally store call log records and other subscriber-specific information related to network service delivery. This stored information in effect comprises a distributed database of virtually unlimited scalability. New service opportunities are made possible by virtue of the fact that this information may be securely accessed by an application and subsequently presented to an end user within the context of interactive calling services. As an example, network-based web applications may be created to provide end users access to multi-year call histories managed through a web browser-based graphical user interface.

[0138] Because of its SIP-based network signaling model, the EDGE SWITCH can perform complex call control operations that involve SIP network signaling endpoints located virtually anywhere in the network. This support for complex call control operations by the EDGE SWITCH in effect enables it to function as a distributed call control resource of virtually unlimited scalability. New service opportunities are made possible by virtue of the fact that this capability can be securely accessed by an application and subsequently presented to an end user within the context of interactive calling services. As an example, network-based web applications may be created to provide end users the ability to access EDGE SWITCH calling features through a web browser-based graphical user interface.

[0139] EDGE SWITCH call control operations can be used to transparently access network-based features provided by APPLICATION SERVERS. As a result, combinations of call control features internal to the EDGE SWITCH and network-based features that are external to the EDGE SWITCH can be dynamically configured and presented together to end users as a unified service or capability—that is, presented in such a way that the source of the feature (internal to the EDGE SWITCH or network-based) is entirely transparent to the end users. Thus, beyond its ability to support programmable internal feature sets via software upgrades and configurable call processing applications, the EDGE SWITCH feature set may be further extended through transparent integration with network-based features. As an example, an EDGE SWITCH feature may be created to override basic dial-tone service: when an EDGE SWITCH detects that a telephone plugged into it went off-hook, the override feature would forgo the basic dial-tone service and instead transparently connect to a network-based voice-activated dialing application.

[0140] In general, in one aspect, the invention features a network device including a plurality of communication interfaces, among which there is a telephone line interface, a computer data interface, and a broadband network interface. The network device also includes a processor; a machine-readable storage medium which during use stores a call processing application and service profiles, and which stores executable instructions to mediate communications between the plurality of communication interfaces, the instructions causing the network device to detect network signaling events or trigger points in a telephone call and invoke the call processing application in response to the detected network signaling events or trigger points, the call processing application operating according to parameters defined in the service profiles.

[0141] Preferred embodiments include one or more of the following features. The plurality of communication interfaces further includes a video streaming device interface. The broadband network interface terminates a broadband network link that joins a customer premises to a packet carrier network. The instructions further cause the network device to route IP data between the computer data interface and the broadband network interface. The network device is contained in a single physical enclosure. The instructions further cause the network device to provide a first SIP proxy agent to represent a telephone that uses the telephone line interface, and provide a second SIP proxy agent to represent a computer that uses the computer data interface. The storage medium stores call routing tables, and the instructions further cause the network device to perform call routing for telephone calls that use the telephone line interface. The storage medium also stores call routing tables, and the instructions cause the network device to perform call routing for telephone calls according to the call routing tables, the telephone calls using the telephone line interface.

[0142] In general, in another aspect, the invention features a network device including a plurality of communication interfaces among which there is a telephone line interface, a computer data interface, and a broadband network interface. The network device also includes a processor; a machine-readable storage medium which during use stores call routing tables, and which stores executable instructions to mediate communications between the plurality of interfaces, the instructions causing the network device to perform call routing according to the call routing tables, the telephone calls using the telephone line interface.

[0143] Preferred embodiments include one or more of the following features. The call routing includes peer-to-peer call signaling between customer premises over a shared IP network. The call signaling is performed without requiring stateful elements of the shared IP network above the IP infrastructure. The broadband network interface terminates a link that joins the network device to the shared IP network. The call routing includes call signaling to a PSTN endpoint via a PSTN gateway that is reachable over the broadband network interface. The instructions further cause the network device to route IP data between the computer data interface and the broadband network interface. And the plurality of communication interfaces further includes a video streaming device interface.

[0144] In general, in still another aspect, the invention features a network device including a plurality of communication interfaces, among which there is a telephone line interface, a computer data interface, and a broadband network interface. The network device also includes a processor; and a machine-readable storage medium which stores executable instructions to mediate communications between the plurality of interfaces, the instructions causing the network device to log a telephone event record to a telephone event repository, the event record describing a telephone call communication mediated by the network device.

[0145] Preferred embodiments include one or more of the following features. The telephone event repository can be included in the network device or be remote relative to the network device. The network device is housed in a single physical enclosure.

[0146] In general, in still yet another aspect, the invention features a network device includes a broadband network interface; a plurality of interfaces, among which there is a telephone line interface and a computer data interface; a processor; and a machine-readable storage medium that stores processor-executable instructions to provide proxy agents. The instructions cause the network device to provide a telephone SIP proxy agent to represent a non-SIP telephone that uses the telephone line interface; provide a distinct SIP proxy agent for each additional device that uses an interface in the plurality of interfaces; and cause the network device to implement a proxy server that mediates all SIP communications over the broadband network interface involving the non-SIP telephone and the each additional devices.

[0147] In general, in another aspect, the invention features a method for establishing a voice-over-packet network architecture. The method includes locating a system management platform in a shared packet network, the system management platform collecting call log data from a plurality of network devices; and distributing the plurality of network devices that each include a telephone line interface, a computer data interface, a broadband network interface terminating a link from the shared packet network, a processor, and a machine-readable storage medium storing processor-executable instructions to control telephone calls, the instructions causing each network device to route telephone calls in a peer-to-peer fashion over the shared packet network and to send call log data to the system management platform.

[0148] The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims.