Patent Application
20080253771
An Optical Network Terminal (ONT) uses ONT operating parameters to operate in a Passive Optical Network (PON). Examples of ONT operating parameters include parameters for ATM Adaptation Layer Type 1 (AAL 1)/Session Initiation Protocol (SIP) mode, Ground Start/Loop Start mode, and video administrator state. In general, SIP creates, modifies, and terminates sessions, such as Internet telephone calls, multimedia distribution, and multimedia conferences, with one or more participants, as standardized by Request for Comments (RFC) 3261, entitled, “Session Initiation Protocol,” J. Rosenberg, et al., June 2002.
Currently, the Independent Operating Company (IOC) market does not have an efficient method for configuring Optical Network Terminals (ONTs) in a network, such as, for example, a Session Initiation Protocol (SIP) network. A method and system according to an example embodiment of the present invention is provided that allows a network operator to change services on a large group of Optical Network Terminals (ONTs) in a network at one time through the use of profiles.
According to one embodiment, at least one profile defining internode communications between nodes in a network is configured, and at least one of the profiles is associated with at least one ONT having at least one port to support internode communications between the at least one ONT and another node in the network. A configuration for the at least one ONT is generated based on the at least one profile associated with the at least one ONT, and is forwarded to at least one of the ONTs in response to a request from the at least one ONT.
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.
A description of example embodiments of the invention follows.
Communication of data transmitted between a given OLT 115a and its associated ONTs 135a-135n may be performed using standard communication protocols known in the art. For example, point-to-multipoint (e.g., broadcast with IDs of intended recipients) for transmitting downstream data from the OLT 115a to the ONTs 135a-135n and point-to-point for transmitting upstream data from an individual ONT 135a-135n back to the OLT 115a (e.g., time division multiple access (TDMA)).
The PON 100 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 applications. The optical fiber 127, 133 in the PON 100 may operate at bandwidths such as 155 Mb/sec, 622 Mb/sec, 1.25 Gb/sec, and 2.5 Gb/sec or any other desired bandwidth implementation. The PON 100 may incorporate asynchronous transfer mode (ATM) communications, broadband services such as Ethernet access and video distribution, Ethernet point-to-multipoint topologies, native communications of data and time division multiplex (TDM) formats, and other communications suitable for a PON. Customer premise equipment (e.g., inside homes 140) that can receive and provide communications in the PON 100 may include standard telephones (e.g., PSTN and cellular), Internet Protocol telephones, Ethernet units, video devices, computer terminals, digital subscriber line connections, cable modems, wireless access, as well as any other conventional customer premise equipment.
The OLT 115a generates or passes through downstream communications 120 to an OSC 125. After passing through the OSC 125, the downstream communications 130 are broadcast to the ONTs 135a-135n, where each ONT 135a-135n reads data 130 intended for that particular ONT 135a-135n using, for example, identification information embedded within the communications signal. Data communications 137 may be further transmitted to and from, for example, a user's home 140 in the form of voice, data, video, and/or telemetry over copper, fiber or other suitable connection 138 as known to those skilled in the art. The ONTs 135a-135n transmit upstream communication signals 145 back to the OSC 125 via fiber connections 133. The OSC 125, in turn, combines the ONT 135a-135n upstream communications signals 145 and transmits the combined signals 150 back to the OLT 115a using, for example, a TDM protocol. The OLT 115a may further transmit the communication signals 110 to the WAN 105.
Communications between the OLT 115a and the ONTs 135a-135n occur using a downstream wavelength and an upstream wavelength. The downstream communications from the OLT 115a to the ONTs 135a-135n may be provided at, for example, 622 megabytes per second, which is shared across all ONTs. The upstream communications from the ONTs 135a-135n to the OLT 115a may be provided, at for example, 155 megabytes per second, which is shared among all ONTs 135a-135n connected to the OSC 125.
One approach to this problem involves sending XML pages to an ONT to configure SIP parameters; however, such an approach requires using a SIP protocol stack to operate with the ONTs, which must be licensed at a very large cost. Another approach involves a trivial file transfer protocol (TFTP) method of serving predefined XML pages to the ONTs; however, this approach does not make use of a convenient graphical user interface and is not easily modified for different configurations.
The present method and apparatus overcome the problems associated with the above approaches and allows a network operator to change services on a large group of ONTs 330 at one time through the use of profiles 301. Such profiles 301 are created for users in the network, and for each profile, a single profile is saved in a database 315c, and assigned to multiple ONTs 330. The profile is then propagated to all of the ONTs 330 to which it is assigned. In embodiments that involve configuring ONTs in a SIP network, the ONTs may be configured without use of the SIP protocol stack.
The profiles may include at least one settings profile, at least one services profile, and at least one call features profile. Further, one of the settings profiles, at least one of the services profiles, and at least one of the call features profiles may be associated with the at least one ONT. Additionally, one of the services profiles and one of the call features profiles may be associated with each port of the at least one ONT. It should be noted that at least one of the profiles may be associated with fewer than all of the ONTs.
At least one of the profiles associated with the ONTs may include a polling timer setting, and the ONTs may request configurations based on the polling timer setting. It should be noted that the polling timer setting may specify a time window in which the ONTs may randomly request their configurations. Additionally, the ONTs may request their configurations in response to a “new configuration” alert.
In one embodiment, a system includes an interface to configure at least one profile defining internode communications between nodes in a network, an association module that associates at least one of the profiles with at least one Optical Network Terminal (ONT), a configuration generation module that generates a configuration for the at least one ONT based on the at least one profile associated with the at least one ONT, and a communication module that forwards the configuration to at least one of the ONTs in response to a request from the at least one ONT. It should be noted that each of the ONTs has at least one port to support internode communications between the at least one ONT and another node in the network. Additionally, the system may include an Element Management System (EMS) that alerts the ONTs when a new configuration is available.
In another embodiment, a network includes an interface to configure at least one profile defining internode communications between nodes in a network, and a server that associates at least one of the profiles with at least one optical network terminal, generates a configuration for the at least one ONT based on the at least one profile associated with the at least one ONT, and forwards the configuration to at least one of the ONTs in response to a request from the at least one ONT. As above, it should be noted that each ONT has at least one port to support internode communications between the at least one ONT and another node in the network. Additionally, the interface may be a web browser and the server may include a web service.
In yet another embodiment, an optical network terminal (ONT) includes at least one port to support internode communications between the ONT and another node in a network, and a configuration based on at least one profile defining internode communications between nodes in the network. The ONT also includes a polling mechanism that requests new configurations. The polling mechanism may request configurations based on a timer setting within the configuration, and may request new configurations randomly within a specified window of time.
In an example embodiment, the present invention includes a Configuration Server 310 and a user console (interface) 320. The Configuration Server 310 runs an operating system (such as Linux) and may include three major components: an Application Framework 315a (such as Ruby on Rails), a Web Server 315b (such as Apache), and a Database 315c (such as MySQL).
A user of the system can modify ONT configurations (or profiles) 301 through the interface 320, which may be a web browser in the example embodiment. According to the example embodiment, the profiles 301 are stored in the database 315c of the Configuration Server 310 and are used by the Configuration Server 310 to generate an XML file that is ultimately retrieved by at least one ONT 330. The generated XML file includes two parts: a global ONT configuration, or ONT settings (such as a transport protocol including a name, port number, and a DSCP value), and per-port, User Agent (UA), configurations (such as an Address of Record (AOR), realm, username, and password). It should be noted that the ONT 330 receives two files from the Configuration Server 310: the XML configuration file and a “trust-anchor” file that includes a certificate for a Proxy Server.
During ONT operation, an ONT 330 may send a request 302 to the Configuration Server 310 asking for the configuration associated with the ONT. The ONT 330 specifies in the request its Dynamic Host Configuration Protocol (DHCP) Client Identifier (its unique ONT name) as a Uniform Resource Identifier (URI) so the Configuration Server 310 may return the appropriate configuration 303 (e.g., in the form of an XML file) to the ONT 330. This polling of the Configuration Server 310 by the ONTs 330 results in less stress on the Configuration Server 310, and reduces the complexity of any software involved. It should be noted that the configuration 303 sent to the ONT 330 may be dynamically created upon the request by the ONT 330 for its configuration.
In this case, when a new configuration is available, the Configuration Server 310 sends a notice 306 of the new configuration to the EMS 350. Upon receiving the notice 306 from the Configuration Server 310, the EMS 350 sends an alert 307 regarding the new configuration to an OLT 360, which passes the alert 307 along to at least one associated ONT 331. When the ONT 331 receives the alert 307, it may then send a configuration request 308 to the Configuration Server 310. Upon receipt of the request 308, the Configuration Server 310 then sends the ONT's configuration 309 to the ONT 331.
The global configuration of an ONT 331 (ONT Settings) allows configuration of a refresh mechanism. This refresh mechanism is designed to minimize an entire network of ONTs 330a-330n (
The Configuration Server 310 may communicate through a separate channel to retrieve additional information for a particular user, such as a specific ONT identifier for the user. This communication enhances the overall ability to provision additional information for users based on information that is already available via the EMS 350. For example, a service-provider may want to configure new services for a particular user. If the user already has other ONT (or similar) services configured via the EMS 350, the feature allows the Configuration Server 310 to retrieve all the necessary information, such as the ONT identifier, Plain Old Telephone Service (POTS), and pre-configured Service Level Agreements (SLAs), for the user from the EMS 350. This retrieval of information avoids manual entry of the several parameters for the user and, thus, avoids the inherent errors associated with manually entering such information. It should be noted that in embodiments that involve SIP networks, no SIP messaging is necessary. The Configuration Server 310 instead uses the separate communication channel to communicate SIP information.
Communications between the Configuration Server 310 and the EMS 350 may be supported by Transaction Language 1 (TL1), XML, or any other standard or proprietary communication technique. Additionally, communications may involve shared access to a database that is managed by the EMS 350.
Each port 420 may also include unique information such as its Address of Record (AOR) and contact Uniform Resource Identifier (URI). The ONT Settings 415, Services settings 425, and Call Features settings 430 may be saved into profiles and associated with an ONT 405 and its ports 420a-420n, accordingly. It should be noted that one ONT settings profile may be associated with many ONTs. Likewise, one Services profile may be associated with many ONT ports, and one Call Features profile may be associated with many ONT ports.
The user may then configure the ONT settings 1125 by selecting an ONT Settings profile 1130 from a list of profiles retrieved from the database 315c (
Once the ONT Settings 1125 have been configured, the user may then configure each port 1140 of the ONT. For each port, the user selects the port number 1145 and selects both a Services settings profile 1150 and a Call Features settings profile 1160 for the selected ONT port 1145. When each profile 1150, 1160 is selected, the settings 1155, 1165 are automatically filled-in according to the selected profiles 1150, 1160. It should be noted that in lieu of selecting profiles 1150, 1160, the user may specify custom settings for the Services settings and Call Features settings by manually entering the information 1155, 1165.
In addition to creating one ONT at a time, a user may create multiple ONT profiles at once. This multiple ONT creation option may clone existing profiles; however, in order for each ONT to have its own unique identifier (DHCP Client ID), a formula is specified by which each new ONT is assigned a unique identifier. An example of such a formula is as follows:
The following is a possible resulting message displayed during the multiple ONT creation using the above formula:
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.
For example, the user interfaces used in configuring profiles and ONTs may include additional features, such as a sort feature that allows a user to sort elements displayed by certain attributes (e.g., sorting by the names of the profiles). An additional feature may include a search feature that allows a user to search for certain attributes (e.g., searching by profile name or address of record). Additionally, the present invention may include a feature that provides statistics and graphs relating to information stored in the Configuration Server 310 (
It should be understood that the flow diagrams of
It should be noted that illustrated embodiments of some of the techniques described herein are described as using the Session Initiation Protocol (SIP). A version of the SIP protocol that may adapted for use with the techniques described herein is described in J. Rosenberg et al., “SIP: Session Initiation Protocol,” RFC 3261, June 2002, which is available from the Internet Engineering Task Force (IETF) and which is incorporated herein by reference in its entirely. It should be noted that other protocols and communication techniques may be adapted to be used with the techniques described herein.
This application claims the benefit of U.S. Provisional Application No. 60/923,429, filed on Apr. 13, 2007. The entire teachings of the above application are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60923429 | Apr 2007 | US |
