US20090268606A1 - Method and apparatus for detecting and correcting faults in a session initiation protocol (sip) network - Google Patents

Abstract

Malfunctions in a communications network may introduce an unacceptably low level of reliability for many users, thereby slowing further adoption of Internet Protocol (IP) telephony, for example. In an example embodiment of the present invention, a method and corresponding apparatus for supporting a call in a presence of a fault in a network is provided. The method includes supporting a primary protocol to service a call between near-end and far-end access nodes associated with two or more callers. Signaling information in the primary protocol supporting the call may be identified and used to establish a backup protocol between the near-end and far-end access nodes. The primary protocol may be monitored for a fault and, in an event a fault occurs, supporting the call using the backup protocol. As a result, IP telephony may be transported in a more reliable manner, thereby reducing the number of dropped and uncompleted calls.

Description

BACKGROUND OF THE INVENTION
• The popularity and convenience of Internet communications, as well as an increasing availability of broadband Internet connections, has resulted in a transformation of existing applications and services. Migration of traditional Public Switched Telephone Networks (PSTN) to Internet Protocol (IP) telephony is one such example. Also known as Voice Over IP (VoIP), IP telephony can provide real-time delivery of voice, video, and other multimedia content (herein collectively “data”), across a network using IP. Voice information is converted into packets and transmitted between or among users over an IP network, effectively allowing telephone calls to be made over the Internet.
• IP telephony offers a number of advantages over PSTN networks, such as reduced costs and new features due to convergence of voice and data. However, in order for IP telephony to continue to displace PSTN service, it must have the same high reliability that users of traditional PSTN systems have come to expect.
• IP telephony is session-based rather than connection based as used in PSTN systems. A signaling protocol, such as Session Initiation Protocol (SIP), may be used to create, modify, and terminate sessions with one or more participants. Sessions may include IP telephone calls, multimedia conferences, and multimedia distribution. Participants can be people or automation components, such as a voicemail server. Because SIP is an application layer protocol, it is transparent to the underlying data link layer.
• IP telephony traffic is often carried over high-speed networks, such as a passive optical network (PON). PONs have emerged as a popular network architecture owing to their compelling economic advantages over other network architectures. In addition, a PON's point-to-multipoint architecture has a significant density advantage over point-to-point copper connections used with traditional PSTN systems.
• A PON system can malfunction in a way such that the system may not be able to complete a new voice call, or inadvertently terminate in session calls. Existing error detection techniques, such as those described in various PON protocol standards, may not detect this type of malfunction or, if detected (e.g., generic system failure message), may not be identified. These types of malfunctions may introduce an unacceptably low level of reliability for many users thereby slowing further adoption of IP telephony.
SUMMARY OF THE INVENTION
• A method and corresponding apparatus for supporting a call in a presence of a fault in a network according to an example embodiment of the invention may support a communications protocol among multiple communications protocols to service a call between near-end and far-end communications devices. The example method may identify parameters of the call in a primary protocol and instantiate a backup protocol between a near-end access node and a far-end access node associated with the communications devices based on at least one of the parameters. The example method may further monitor the primary protocol for a fault and, in an event of a fault, support the call using the backup protocol.
BRIEF DESCRIPTION OF THE DRAWINGS
• The foregoing will be apparent from the following more particular description of example embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments of the present invention.
• FIG. 1 is a network diagram of a Passive Optical Network (PON) employing an example embodiment of the invention;
• FIG. 2 is a block diagram of an example portion of a network employing an example embodiment of the invention;
• FIG. 3 is a more detailed block diagram of a portion of a network employing an example embodiment of the invention;
• FIG. 4 is a flow diagram performed in accordance with an example embodiment of the invention;
• FIGS. 5-7 are flow diagrams illustrating procedures performed in accordance with an example embodiment of the invention; and
• FIG. 8 is a block diagram of the internal structure of a computer in which example embodiments of the invention may be implemented.
DETAILED DESCRIPTION OF THE INVENTION
• A description of example embodiments of the invention follows.
• Network service providers are increasingly deploying fiber optic transmission media deeper and deeper into the network infrastructure. As a result, fiber-optic media is beginning to replace copper twisted pair media in many applications. For example, communications signals formerly transmitted across copper wires are now transmitted across a fiber-optic media. Consequently, new applications such as Voice over Internet Protocol (VoIP) are becoming increasingly commonplace. Although VoIP is attractive from a feature and price point of view, continued acceptance requires, in part, the same high reliability which users have become accustomed to with respect to traditional switching networks.
• FIG. 1 is a network diagram100 depicting aspects of an example embodiment of the invention illustrating a signaling protocol for use with VoIP communications for creating, modifying, and terminating sessions between one or more participants. Example protocols include session initiation protocol (SIP), described in IETF RFC 3261, “SIP: Session Initiation Protocol,” June 2002, http://www.ietf.org/rfc/rfc3261.txt, International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Recommendation H.323, “Packet-based multimedia communication systems,” November 2000, and ITU-T Recommendation H.225, “Call signaling protocols and media stream packetization for packet-based multimedia communication systems,” November 2000, all of which are incorporated herein by reference in their entirety.
• A typical Passive Optical Network (PON)100 includes an optical line terminal (OLT)115, a passive optical splitter/combiner (OSC)125, and at least one optical network node, such as an optical network terminal (ONT)135a-nor an optical network unit (ONU)160a-n. The PON may also include an element management system (EMS) in communication with, for example, the OLT115. Note that as used herein, an ONU and an ONT may be used interchangeably unless indicated otherwise. Further note that “Data” as used herein refers to voice, video, analog, or digital data. The ONT135a-nmay be in optical communication with multiple end users140a-n.Data communications110 may be transmitted to the OLT115 from a wide area network (WAN)105. Content server(s)107 orother user networks106 provide communications signals to and from theWAN105.
• A SIP telephone network may be implemented using, in part, aPON100. In thePON100, communication ofdownstream data120 andupstream data150 transmitted between the OLT115 and the ONTs135a-nmay be performed using standard communications protocols known in the art. For example, multicast may be used to transmit thedownstream data120 from the OLT115 to the ONTs135a-n, and time division multiple access (TDMA) may be used to transmit theupstream data150 from an individual ONT135a-nback to the OLT115. Note that thedownstream data120 is power divided by theOSC125 intodownstream data130 matching thedownstream data120 “above” theOSC125 but with power reduced proportionally to the number of paths onto which the OSC125 divides thedownstream data120. It should be understood that the term downstream data (e.g.,downstream data120,130) refers to optical traffic signals that travel from the OLT115 to the ONT(s)135aand end user(s)140a-n, and “upstream data” (e.g.,upstream data145a,150) refers to optical traffic signals that typically travel from the end users140a-nand ONTs135a-nto the OLT115 via optical communications paths, such asoptical fiber links131,127, and in some networks, link135.
• ThePON100 may be deployed for fiber-to-the-premise (FTTP), fiber-to-the-curb (FTTC), fiber-to-the-node (FTTN), and other fiber-to-the-X (FTTX) applications. Theoptical fiber127 in the PON may operate at bandwidths such as 155 megabits per second (Mbps), 622 Mbps, 1.25 gigabits per second (Gbps), and 2.5 Gbps or other bandwidth implementations. The PON may incorporate asynchronous transfer mode (ATM) communications, broadband services such as Ethernet access and video distribution, Ethernet point-to-multipoint topologies, and native communications of data and time division multiplexing (TDM) formats or other communications suitable for a PON. End users140a-nmay receive and provide communications from and to, respectively, the PON and may be connected to Internet Protocol telephones, video devices, Ethernet units, digital subscriber lines, computer terminals, wireless access, as well as any other conventional customer premise equipment.
• The OLT115 generates, or passes through,downstream communications120 to an OSC125. After flowing through theOSC125, thedownstream communications120 are transmitted as power reduceddownstream communications130 to the ONTs135a-n, where each ONT135a-nmay filter and replicatedata130 intended for a particular end user140a-c. Thedownstream communications120 may also be transmitted to, for example, anotherOSC155 where thedownstream communications120 are again split and transmitted to additional ONT(s)160a-nand end user(s)140n.
• Data communications137 may further be transmitted to and from, for example, end user(s)140a-nin the form of voice, video, data, and/or telemetry over copper, fiber, or othersuitable connection138 as known to those skilled in the art. The ONTs135a-nmay transmit upstream communication signals145a-nback to the OSC125 viafiber connections133 using transmission protocols known in the art, such as Internet Protocol (IP) enabling applications such as VoIP. The OSC125, in turn, combines the ONT's135a-nupstream signals145a-nand transmits a combinedsignal150 back to the OLT115 which may, for example, employ a time division multiplex (TDM) protocol to determine from which ONTs135a-nportions of the combinedsignal150 are received. The OLT115 may further transmit thecommunication signals112 to aWAN105, back downstream to other ONTs connected to the OLT, or both.
• Communications between theOLT115 and the ONTs135a-noccur using a downstream wavelength, for example 1490 nanometer (nm), and an upstream wavelength, for example of 1310 nm. Thedownstream communications120 from the OLT115 to the ONTs135a-nmay be provided at 2.488 Gbps, which is shared across all ONTs. The upstream communications145a-nfrom the ONTs135a-nto theOLT115 may be provided at 1.244 Gbps, which is shared amongst all ONTs135a-nconnected to theOSC125. Other communication data rates known in the art may also be employed.
• Communications between end users140a-nmay travel across multiple PONs andmultiple networks105,106. For example, anotherPON100, such as that represented byOLT117,OSC119, andONT121, may be connected to theWAN105 or toother user networks106 and may operate in a manner similar to that described above with respect toOLT115,OSC125, ONTs135a-n, and end users140a-n. Thus, communications may travel between end users within the same PON or may traverse multiple PONs and/or networks.
• A SIP network may be enhanced by providing error detection and backup connection techniques in an event errors are detected. A phone call between two or more users, for example,End Users140aand140n, may be supported usingdownstream communications130,132 andupstream communications145n,147 via a primary protocol. The ONT(s)121,160nassociated with theEnd Users140a,140nmay be configured to identify call parameters in the primary protocol and, based on the parameter, instantiate a backup protocol between theEnd Users140a,140n. The primary protocol may be monitored for faults, and in the event a fault occurs, the called can be switched to the backup protocol, thereby preventing the call from being dropped.
• Instantiating a backup protocol is defined herein as creating, modifying, and terminating sessions with one or more participants such as is described in Request For Comments (RFC) 3261, “SIP: Session Initiation Protocol,” June 2002, incorporated herein by reference in its entirety. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.
• An example method and corresponding apparatus for supporting a communications protocol among multiple communications protocols to service a call between near-end and far-end communications devices may include identifying parameters (e.g., source or destination identification (ID)) of the call in a primary protocol. The example method may include instantiating a backup protocol between a near-end access node and a far-end access node associated with the communications devices based on at least one of the parameters. The example method may further include monitoring the primary protocol for a fault and, in an event of a fault, support the call using the backup protocol. Example communications protocols may include ATM adaptation layer 1 (AAL1), AAL2, TDM, ATM, Internet protocol (IP), wireless, or similar such protocols known in the art. Example network nodes may include an ONT, ONU, or OLT.
• An alternative embodiment may further include identifying the far-end source ID of an incoming call or destination ID of an outgoing call and providing the ID to disable a ‘call busy state’ to enable instantiation of the backup protocol to support caller ID blocking. A unique identifier may be used to identify the source ID or destination ID. Identifying parameters of the call may also include parsing Session Initiation Protocol (SIP) packets to identify the parameters of a call, including a source ID or destination ID using at least one of the following identifiers: a media access control (MAC) address, IP address, or telephone number
• In another example embodiment, the technique may further include configuring the primary and backup protocols prior to establishing the call via the primary protocol. The backup protocol may be instantiated after establishing the call via the primary protocol. In this way, the backup protocol may be activated prior to a call being inadvertently dropped. The example embodiment may further include reestablishing the call via the backup protocol after a drop of the call. The active protocol may use a SIP where a “ping” rate on the SIP is increased to determine its availability in order to reestablish the call via the primary protocol. The primary protocol may be monitored while the call is being serviced by the backup protocol, and if the primary protocol becomes available again during the call, the call may be returned to the primary protocol.
• In yet another example embodiment, identifying parameters may include identifying a call priority identifier among the identified parameters, such that a 911 call, enhanced 911 call, or emergency service call may be recognized. The technique may further include determining service usage fees based on instantiating the backup protocol or supporting the call using a backup protocol.
• In still another example embodiment, a computer program product may be used to support a call in a network where the computer program product includes a computer readable medium having computer readable instructions stored thereon, which, when loaded and executed by a processor, cause a processor to support any combination of the foregoing procedures.
• It should be noted that a call may refer to a traditional telephone voice call, but should not be viewed as limited to such, and may also include transmission of any variety of multimedia content such as video, audio, multimedia conferencing, gaming, distant education, and the like.
• FIG. 2 is a block diagram of aSIP telephone network200 configured to support communications such as a telephone call260a-bbetween at least one near-end communications device220aand at least one far-end communications device220baccording to an example embodiment of the invention. Thenetwork200 may include one or more PONs connected to aWAN210. TheWAN210 may support multiple communications protocols such as AAL1, AAL2, TDM, ATM, IP, various wireless protocols, or similar such protocols known in the art. TheWAN210 may also include other networks (not shown) such that the call260a-btravels across multiple networks. A call260a-bbetween two communications devices220a-btakes place in the form of downstream communications and upstream communications as was described with reference toFIG. 1.
• The network nodes205a-binclude communications modules230a-b, redundancy set-up modules240a-b, and fault recovery modules250a-b. The communications modules230a-bare configured to support a communications protocol from among multiple communications protocols to service the call between the near-end and far-end communications devices220a-b. Aprimary protocol265 may be initially used to service the call260a-b. The redundancy set-up module240a-bidentifiesparameters275 of the call260a-bin theprimary protocol265, such as a source ID or destination ID. Based on the identifiedparameters275, the redundancy set-up module240a-balso instantiates abackup protocol270 between the near-end device220aand the far-end device220b, thus, effectively providing a backup connection for the call260a-b. The fault recovery module250a-bmay be used to monitor theprimary protocol265 for a fault. In the event a fault occurs with theprimary protocol265, thebackup protocol270 may be used to continue supporting the call260a-b, thereby transparently preventing call termination and providing an additional level of reliability. It should be understood that the redundancy set-up modules240a-band fault recovery modules250a-bcan be configured to operate independently or in a cooperative manner, such as through an exchange of state information or signaling procedure.
• In an alternative embodiment, thebackup protocol270 may be initially used to service the call260a-b. For example, if the primary protocol is265 designated to be the default communications protocol and that protocol is unavailable, the backup protocol may be initially used to make any subsequent calls260a-b. Theprimary protocol265 may be monitored, and should it become available, the call260a-bmay be switched back to theprimary protocol265.
• The one or more PON(s)200 may include an OLT245a-b, OSC235a-b, and network node205a-b, such as an ONT. In a case where the near-end communications device220aand the far-end communications device220bare within the same PON (e.g., ultimately connected to the same OLT), the call may take place within the same PON, and traverse the same physical link within that PON. However, if the communications devices220a-bare not within the same PON (i.e., not connected to the same OLT), at least two PONs may be used conduct the call260a-b, as is the case depicted inFIG. 2. In this case, the call may or may not traverse the same physical link.
• FIG. 3 is a more detailed block diagram of theSIP telephone network300 depicted inFIG. 2. The network includes near-end and far-end communication devices320a-b, network nodes305a-b, and a network such as aWAN310. Note that aSIP telephone network300 may be configured, in part, as one or more PONs as was shown inFIG. 2 and as discussed above; however, inFIG. 3, the OSC and OLT have been omitted for the sake of brevity.
• In an example embodiment, the network node305a-bmay be, for example, an ONT and may include a redundancy set-up module340a-b, communications module330a-b, fault recovery module350a-b, call registration module332a-b, fee determination unit334a-b, and wireless interface336a-b. The redundancy set-up module340a-bmay further include a configuration module346a-b, parsing module344a-b, and priority identification unit342a-b. The fault recovery module350a-bmay further include an activation module352a-b.
• In this embodiment, a call360a-bmay, for example, be initiated by a user at the near-end communications device320ato a user at the far-end communications device320b. Thecall registration module332aassociated with the near-end communications device320a(i.e., caller) may identify the destination ID of the far-end communications device320b(i.e., callee). Upon receiving thecall360bat the callee'snetwork node305b, thecall registration module332bassociated with the far-end communications device320bmay identify a call parameter, such as a source ID of the calling device.
• Traditional telephone calls typically do not allow more than one simultaneous connection per call. In the event a second call is received while another call is in progress, a call busy state is indicated. To enable both primary and backup connections simultaneously, in one example embodiment, the call registration module332a-bprovides the source and destination ID to the redundancy set-up module340a-bin order to disable a “call busy state” in order to enable instantiation of thebackup protocol370 to support caller ID blocking.
• The parsing module344a-bmay be used to parse packets to identifyvarious call parameters375. For example, the parsing modules344a-bmay be used to parse SIP packets to identify acall parameter375, such as a MAC address, IP address, telephone number, or other such identifier, and may associate a unique identifier with a corresponding source ID or destination ID.
• Continuing to refer toFIG. 3, the configuration module346a-bmay be used to configure theprimary protocol365 andbackup protocol370 for the call360a-b. Theprimary protocol365 andbackup protocol370 may be configured prior to establishing the call via, for example, the primary protocol. Theprimary protocol365 andbackup protocol370 may use various communications protocols, such as, for example, AAL1, AAL2, SIP, TDM, ATM, TDM, ATM, IP, or similar such protocols. In addition, or alternatively, the wireless interfaces336a-bmay be used to enable use of various wireless protocols, such as TDMA, code division multiple access (CDMA), global system for mobile communications (GSM), or similar wireless protocols known in the art.
• After the call360a-bhas been established using theprimary protocol365, the configuration module346a-bmay instantiate thebackup protocol370, thus, providing a backup connection for the call360a-b. After thebackup protocol370 has been instantiated, the activation module352a-bmay activate thebackup protocol370 at any time in order to provide a seamless transition between protocols. That is, because the call360a-beffectively maintains two simultaneous connections (i.e., primary and backup protocol), in the event the primary connection is dropped, the activation module352a-bmay reestablish the call via thebackup protocol370.
• While the call360a-bis being maintained by thebackup protocol370, the activation module352a-bmay also be configured to monitor theprimary protocol365 and, in the event theprimary protocol365 becomes available during the call360a-b, the call360a-bmay be switched back or returned to theprimary protocol365. For example, if theprimary protocol365 uses SIP, the activation module352a-bmay increase a ping rate on the SIP to determine its availability in order to reestablish the call via theprimary protocol365.
• The ability to monitor theprimary protocol365 while thebackup protocol370 is being used to support the call360a-bmay be advantageous in the situation where theprimary protocol365 andbackup protocol370 are associated with different usage fees. For example, calls360a-bserviced using a SIP protocol may be less expensive than calls using, for example, an ATM protocol. Thus, a more expensive backup protocol may be used only when necessary. In addition, the network node305a-bmay also include a fee determination unit334a-bthat may be used to determine service usage fees based on instantiation or support of the call360a-busing thebackup protocol370.
• The priority identification unit342a-bmay also identify a call priority identifier among thecall parameters375. For example, the call priority identifier may represent or be associated with a 9-1-1 call, enhanced 9-1-1 calls, or similar such emergency call. Enhanced 9-1-1 refers to the an emergency calling system that automatically associates a physical address with a calling party's telephone number. The priority identification unit342a-bmay also be configured to undertake further action based on the identified call priority.
• FIG. 4 illustrates, in the form of a flow diagram, an example embodiment of the present invention. It should, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the example embodiment. For example, some of the flow diagrams presented herein, includingFIG. 4, may be performed in an order other than that which is described. It should be appreciated that not all of the flow diagrams are required to be performed, that additional flow diagram(s) may be added, and that some may be substituted with other flow diagram(s).
• Theprocedure400 depicted inFIG. 4 begins (405) and supports a communications protocol from among multiple protocols to service a call between at least two communications devices (410). Theprocedure400 may identify call parameters in a primary protocol (415). Theprocedure400 may then instantiate a backup protocol between at least two access nodes associated with the at least two communications devices based on the identified call parameters (420). After the primary protocol and backup protocol have been established, the procedure may monitor the primary protocol for a fault (425). In the event of a fault (430), the procedure may support the call using the backup protocol (435). The procedure may end (440) when, for example, the calling parties terminate the call.
• Some or all of the steps in theprocedure400 may be implemented in hardware, firmware, or software. If implemented in software, the software may be (i) stored locally with the OLT, ONT, End User communications device, or some other remote location such as a server or the EMS, or (ii) stored remotely and downloaded to the OLT, ONU, End User communications device, or the EMS during, for example, start405. The software may also be updated locally or remotely. To begin operations in a software implementation, the OLT, ONU, End User communications device, or EMS loads and executes the software in any manner known in the art.
• FIG. 5 is a flow diagram of aprocedure500 illustrating an alternative example embodiment of the procedure described with reference toFIG. 4. In this embodiment, support of a communications protocol to service a call between communications devices (505) may include determining if the primary protocol uses a SIP protocol (510). If not, the procedure returns (520) toFIG. 4. If a SIP protocol is in use, the procedure may parse packets to identify particular call parameters (515), such as a MAC address, IP address, telephone number, or the like. These parameters may be used to associate a unique identifier with a particular communications device or access node. The procedure then returns (520) toFIG. 4. In an alternative embodiment, the same procedure may be used except that a backup protocol is examined for use of a SIP protocol.
• FIG. 6 is a flow diagram of aprocedure600 according to another alternative example embodiment. In this embodiment, identifying call parameters in a primary protocol (605) may further include determining if, for example, a call's caller ID is blocked (610). If not, the procedure returns (625). If caller ID is blocked (610), the procedure may identify a source ID of an incoming call or destination ID of an outgoing call (615) and disable a call busy state (620). The procedure then returns (625) toFIG. 4.
• FIG. 7 is a flow diagram of aprocedure700 illustrating yet another alternative embodiment. Theprocedure700 may instantiate the backup protocol after establishing the call via the primary protocol (710). After the backup protocol and been instantiated, it may be activated prior to a call being dropped (715), thereby providing a redundant connection. Theprocedure700 may determine if an established call has been dropped (720) and, if not, theprocedure700 returns (745) toFIG. 4. If the call is dropped from the primary protocol, the call may be reestablished via the backup protocol (725).
• Theprocedure700 may determine if the active protocol uses SIP (730) and, if so, theprocedure700 may increase the SIP's ping rate to determine its availability for the purpose of, for example, reestablishing the call via the primary protocol (735). For example, in the situation where SIP is the primary protocol and TDM/ATM is the backup protocol, and due to an error of some sort, the call is switched to the backup protocol. The procedure may increase the SIP's ping rate (e.g., increasing the rate to 1 second) such that when the primary protocol becomes available, the call may be switched back to use the SIP.
• Theprocedure700 may continue to monitor the primary protocol during support of the call by the backup protocol and, in the event the primary protocol becomes available to call, support of the call may be returned to the primary protocol (740). Theprocess700 may then return (745).
• It should be readily appreciated by those of ordinary skill in the art that the aforementioned procedures are merely exemplary and that the example embodiments are in no way limited to the number of actions or the ordering of steps described above.
• In another alternative example embodiment where the primary protocol uses a SIP, the SIP network may be configured to implement “keep alive” messages at a non-standard rate. For example, rather than a standard rate of say 10 minutes, the keep alive message rate may be increased to 1 second such that the messages cover the entire span of an active call from one device associated with an ONT to another device associated with another ONT. This much finer level of granularity allows the ONT to determine error conditions quickly. The ONT may further report an alarm and/or initiate corrective action.
• In this embodiment, if both ONT's have access to the same backup protocol (e.g., TDM/ATM), a backup protocol may be instantiated and activated in less time that it takes for a call to be dropped. Consequently, the backup protocol is provided only when the primary protocol becomes problematic. That is, the primary and backup protocols do not need to be simultaneously available. For example, consider a SIP network where each ONT uses SIP as the primary protocol and each ONT has access to the same backup protocol (e.g., TDM). In the event a problem occurs with the primary protocol (i.e., SIP), the primary protocol can be abandoned, and the originating ONT can automatically call the other ONT(s) using the backup protocol via a TDM/ATM network using an AAL1 or AAL2 connection.
• In the event there are no problems with the primary protocol, the backup protocol need not be enabled. Furthermore, if a call is not in progress and the SIP network is not available, the ONT may initiate new calls using the backup TDM network until the SIP network is restored.
• Although the apparatus and method described herein discuss transporting downstream and upstream communications signals using a fiber optic media in a PON, the example embodiments are not meant to be limited to such a media or network architecture. It should be understood that the example embodiments can be implemented, in part, or in its entirely, using alternative physical media such a coaxial (or similar) wire such as a cable media commonly used to deliver television, VoIP, and/or Internet services to an end user's premise.
• Further, the Sessions Initiation Protocol as well as the instructions to transmit and receive SIP messages may reside on a computer-readable medium. The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device. Volatile media includes dynamic memory, such as main memory. Transmission media includes fiber optics, copper wires and coaxial cables, including the wires that comprise bus. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.
• Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, or any other optical medium, RAM, PROM, EPROM, FLASH, or any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
• While this invention has been particularly shown and described with references to example embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.

Claims (35)

1. A network node, comprising:

a communications module configured to support a communications protocol among multiple communications protocols to service a call between near-end and far-end communications devices;

a redundancy set-up module to identify parameters of the call in a primary protocol and instantiate a backup protocol between a near-end access node and a far-end access node associated with the communications devices based on at least one of the parameters; and

a fault recovery module to monitor the primary protocol for a fault and, in an event of a fault, support the call using the backup protocol.

2. The network node according toclaim 1 wherein the parameters include a source identification (ID) or destination ID.

3. The network node according toclaim 1 further comprising a call registration module configured to identify the far-end source ID of an incoming call or destination ID of an outgoing call and provide the ID to the redundancy set-up module to disable a ‘call busy state’ to enable instantiation of the backup protocol to support caller ID blocking.

4. The network node according toclaim 3 wherein the call registration module is further configured to use a unique identifier to identify the source ID or destination ID.

5. The network node according toclaim 1 wherein the redundancy set-up module includes a parsing module to parse Session Initiation Protocol (SIP) Packets to identify the parameters of a call, including a source or destination ID having at least one of the following identifiers: MAC address, IP address, or telephone number.

6. The network node according toclaim 1 wherein the communications protocols include at least one of the following: AAL1, AAL2, TDM, ATM, IP, or wireless.

7. The network node according toclaim 1 wherein the network node is an optical network terminal (ONT) or an optical line terminal (OLT) in a passive optical network (PON).

8. The network node according toclaim 8 wherein the network node includes a wireless interface and wherein the backup protocol includes a wireless protocol.

9. The network node according toclaim 1 wherein the redundancy set-up module includes a configuration module to configure the primary and backup protocols prior to establishing the call via the primary protocol.

10. The network node according toclaim 1 wherein the redundancy set-up module includes a configuration module to instantiate the backup protocol after establishing the call via the primary protocol.

11. The network node according toclaim 1 wherein the fault recovery module includes an activation module to activate the backup protocol prior to a drop of the call.

12. The network node according toclaim 1 wherein the fault recovery module includes an activation module configured to reestablish the call via the backup protocol after a drop of the call.

13. The network node according toclaim 12 wherein the primary protocol uses a SIP and wherein the activation module is configured to increase a ping rate on the SIP to determine its availability to reestablish the call via the primary protocol.

14. The network node according toclaim 1 wherein the fault recovery module includes an activation module configured to monitor the primary protocol during support of the call by the backup protocol and return the call to the primary protocol if it becomes available again during the call.

15. The network node according toclaim 1 wherein the redundant set-up module further includes a priority identification unit configured to identify a call priority identifier among the parameters and to take action based on the call priority identifier.

16. The network node according toclaim 15 wherein the call priority identifier is representative of at least one of the following: a 9-1-1 call, enhanced 9-1-1 call, or emergency service call.

17. The network node according toclaim 1 further including a fee determination unit configured to determine service usage fees based on an instantiation of the backup protocol or support of the call using a backup protocol.

18. A method to support a call in a presence of a fault in a network, the method comprising:

supporting a communications protocol among multiple communications protocols to service a call between near-end and far-end communications devices;

identifying parameters of the call in a primary protocol;

instantiating a back-up protocol between a near-end access node and a far-end access node associated with the communications devices based on at least one of the parameters; and

monitoring the primary protocol for a fault and, in an event of a fault, supporting the call using the backup protocol.

19. The method according toclaim 18 wherein the parameters include a source identification (ID) or destination ID.

20. The method according toclaim 18 further including identifying the far-end source ID of an incoming call or destination ID of an outgoing call and providing the ID to disable a ‘call busy state’ to enable instantiation of the backup protocol to support caller ID blocking.

21. The method according toclaim 20 further including using a unique identifier to identify the source ID or destination ID.

22. The method according toclaim 18 wherein identifying parameters of the call includes parsing Session Initiation Protocol (SIP) packets to identify the parameters of a call, including a source ID or destination ID having at least one of the following identifiers: MAC address, IP address, or telephone number.

23. The method according toclaim 18 wherein the communications protocols include at least one of the following: AAL1, AAL2, TDM, ATM, IP, or wireless.

24. The method according toclaim 18 wherein the network node is an optical network terminal (ONT) or an optical line terminal (OLT) in a passive optical network (PON).

25. The method according toclaim 18 wherein the backup protocol includes a wireless protocol.

26. The method according toclaim 18 further including configuring the primary and backup protocols prior to establishing the call via the primary protocol.

27. The method according toclaim 18 wherein instantiating the backup protocol includes instantiating the backup protocol after establishing the call via the primary protocol.

28. The method according toclaim 18 further including activating the backup protocol prior to a drop of the call.

29. The method according toclaim 18 further including reestablishing the call via the backup protocol after a drop of the call.

30. The method according toclaim 29 wherein the active protocol uses a SIP and further including increasing a ping rate on the SIP to determine its availability to reestablish the call via the primary protocol.

31. The method according toclaim 18 further including monitoring the primary protocol during support of the call by the backup protocol and returning the call to the primary protocol if it becomes available again during the call.

32. The method according toclaim 18 wherein identifying parameters includes identifying a call priority identifier among the parameters.

33. The method according toclaim 32 wherein the call priority identifier is indicative of at least one of the following: a 9-1-1 call, enhanced 9-1-1 call, or emergency service call.

34. The method according toclaim 18 further including determining service usage fees based on instantiating the backup protocol or supporting the call using a backup protocol.

35. A computer program product for supporting a call in a presence of a fault in a network, the computer program product comprising a computer readable medium having computer readable instructions stored thereon, which, when loaded and executed by a processor, cause the processor to:

support a communications protocol among multiple communications protocols to service a call between near-end and far-end communications devices;

identify parameters of the call in a primary protocol;

instantiate a back-up protocol between a near-end access node and a far-end access node associated with the communications devices based on at least one of the parameters; and

monitor the primary protocol for a fault and, in an event of a fault, support the call using the backup protocol.

Images