Not Applicable.
The present invention relates in general to the provision of voice over Internet Protocol (VoIP), High Speed Internet and Video all delivered over the same communications network.
There is generally one residential gateway (RG) 106 and one DSLAM 100 port per service subscriber residence 50. When traffic exits through the DSLAM, a Virtual Local Area Network (VLAN) ID is assigned to each traffic flow from each subscriber. At the Ethernet Service Switch 104, one Service Access Point (SAP) 108 is provisioned per subscriber. The Ethernet Service Switch 104 divides the traffic into flows on a per subscriber basis according to the type of traffic and sends the traffic flows to their respective destinations (e.g., application servers 132 via service routers 130) in tunnels through the service provider network. A deep packet inspection (DPI) component 110 monitors traffic to detect viruses, monitor Quality of Service (QoS) per subscriber flow, and perform similar functions. The Subscriber Service Controller (SSC) 112 includes a Dynamic Host Configuration Protocol (DHCP) Server 114 for assigning Internet Protocol (IP) addresses to the RGs 106 at their request, and a Policy Manager 116 applies policies to the various Triple Play services and service subscribers.
Elements of the service provider network are managed using an Element Management System (EMS) 124, which stores network element information in an EMS database 126, in a manner known in the art.
The Triple Play subscriber and policy management system (SSC) 112 requires complete information about all resources used by a subscriber to provide monitoring and management of Triple Play Services for the subscriber. However, this information is scattered throughout multiple entities in the customer network and operations support system (OSS) 118—e.g. the RG (residential gateway) 106 used by the subscriber, the DSLAM 100 port assigned to the subscriber, the SAP (Service Access Point) 108 assigned to the subscriber, the aggregating Ethernet service switch 104 serving the subscriber, etc. Further compounding this problem is the number of subscribers that need to be supported, which can be up to 17 million subscribers per SSC 112.
Consolidating this information in the SSC requires complex software that is difficult to design, expensive to develop and must include modules to pull the information from other OSS components, such as a customer lightweight directory access protocol (LDAP) database, a subscriber provisioning system 122 and/or an inventory database.
Alternatively, it has been proposed that modules be developed in other OSS components to push required information to the SSC 112. Either approach, however, requires the development of almost N**2 software modules to facilitate information exchanges between N OSS software components.
It is therefore highly desirable to provide a less complex way of capturing service topology information needed by a Subscriber Service Controller for IP address assignment, policy management, etc. in the provision of Triple Play services.
It is an object of the invention to provide a system and method for capturing service topology information needed by a Subscriber Service Controller to enable Triple Play residential gateway IP address assignment, Triple Play service subscriber policy management, etc.
The invention therefore provides a system for controlling, on a per subscriber basis, the delivery of Triple Play services via a data packet network, comprising: a Dynamic Host Configuration Protocol (DHCP) server; an element management system (EMS) having a database configured to store DHCP information about a subscriber rural gateway and digital subscriber line access module (DSLAM) used to provide the Triple Play services to the subscriber; and a Subscriber Service Controller (SSC) associated with the DHCP server, the SSC being configured to upload per-subscriber DHCP information periodically, or as required, from the EMS database, whereby the uploaded information is used to perform functions to control delivery of the Triple Play services.
The invention further provides a method of managing Triple Play service provision, comprising: configuring an element management system (EMS) database to store DHCP information about network elements used to provide Triple Play service to each service subscriber; and configuring a service subscriber controller to request the DHCP information from the EMS database and to use the information to perform functions to control delivery of the Triple Play services.
Further features and advantages of the present invention will become apparent from the following detailed description, taken in combination with the appended drawings, in which:
It should be noted that throughout the appended drawings, like features are identified by like reference numerals.
The invention provides a method and system for utilizing the database of an Element Management System (EMS) to capture service topology information needed by a Triple Play Subscriber Service Controller (SSC). This is efficient from both an operational and implementation perspective because the EMS already communicates with Operational Support System applications, such as the Provisioning application. Consequently, the EMS already has at least a part of the information required to identify the residential gateway, DSLAM port, and service access port on a per subscriber basis for the SSC.
Specifically, a provisioning application 122a is provisioned to store protocol information—e.g. the DHCP Option 82 information—in the EMS 124a database 126a to capture topological affinity of a SAP 108 to other network resources. The EMS 124a does not interpret this information in any way. The EMS 124a only serves the information to the SSC 112 on demand, thus providing the missing key for subscriber resources information without being aware of the service it is providing in doing so. The SSC 112 interprets this information to discover an associated Ethernet service switch 104 and a SAP 108 and related elements that provide service to the service subscriber.
The SSC 112 and other OSS components are then configured to request DHCP information from the EMS on an as needed basis (208).
The DHCP information data can be further extended using ordered partitioning or replication. In the case of partitioning, multiple relationship elements, called <Tags>, are separated for the use of discovering applications like the SSC 112 (210). Each protocol flow is associated with data within the data field and the <Tags> are used as keys for respective protocol flows. The protocol information is either implicit or encoded as part of the key.
In the replication case, the data field is simply repeated in multiple instances to achieve similar results (212).
The data field can be further extended by adding type information to the field for the purpose of simplifying discovery. (214) In this case, the discovery process captures both the required data and the protocol relationships associated with the required data.
Thereafter, the network provider network uses the DHCP information to manage Triple Play subscriber services (216).
The invention will now be further described by the way of three specific examples.
The provisioning application 122a stores dynamic host configuration protocol (DHCP) Option 82 information as coded in the edge device (DSLAM 100, Ethernet service switch 104, etc) in the EMS 124a database 126a. The DHCP Option 82 information indicates the DSLAM 100 and port information within DHCP Option 82 sub options 1 & 2. A DHCP lease request contains the Option 82 information which the SSC 112 may combine with the local EMS 124a data to derive the Ethernet service switch 104, SAP 108 and DSLAM 100 information. This allows SSC 112 to perform policy actions upon either the SAP 104 or the DSLAM 100, as required, without data filling the SSC 112 with the information.
The EMS 124a database 126a can similarly be configured to store DHCP Option 60 information provided by the RG 106, a host or other device. This provides the SSC 112 with a means for discovering virtual interface to end point mappings.
For example, a RG 106 option 60 field can be data filled into the database 126a and used to identify the RG 106 to a next generation network architecture (TR59) compliant element management system (EMS).
As a further example, a RG 106 certificate can be data filled into the database 126a and used to relay 822.1×, Extensible Authentication Protocol (EAP) or similar port-based authentication methods back to the RG 106.
The method in accordance with the invention can be similarly used for any interface technology through the inclusion of a data field in the EMS database. Similarly, standard description fields available in many system interfaces such as Simple Network Management Protocol Interfaces Group-Management Information Base (SNMP IF MIB) can be leveraged for the purpose of linking protocol information to the EMS 124a for discovery by systems like the SSC 112.
Exemplary Application
An RG 106 in a subscriber's residence 50 requests an IP address from the DHCP Server 114 in the SSC 112. Since the DHCP Server 114 only has information about the SAP 108 that serves the service subscriber's RG 106, it must obtain information about the DSLAM 100 port, or optionally the RG 106 that sent the request, in order to determine a class of the subscriber before the IP address can be assigned. Consequently, the SSC 112 contacts the EMS 124 and uses existing DHCP information in the EMS database 126a to discover required information about the DSLAM 100 port, or the RG 106, respectively.
Although the present invention has been explained with specific reference to Triple Play services, the invention is applicable to assist discovery of any interface technology relationship: e.g., at the physical layer like Ethernet or HDLC, encapsulation-based like Asynchronous Transfer Mode (ATM) Permanent Virtual Circuit (PVC), Ethernet VLAN, virtual interfaces like sub-interfaces or SAPs, or tunnel interfaces like Multiprotocol Label Switching (MPLS), Generic Routine Encapsulation (GRE) or Layer 2 Tunneling Protocol (L2TP)—where it is desirable to relate the connectivity and network element associations for a system like the SSC 112.
The embodiments of the invention described above are therefore intended to be exemplary only. The scope of the invention is intended to be limited solely by the scope of the appended claims.
This application is a continuation of U.S. patent application Ser. No. 11/514,679, filed Sep. 1, 2006, now abandoned.
Number | Name | Date | Kind |
---|---|---|---|
20020023258 | Elwahab et al. | Feb 2002 | A1 |
20020052876 | Waters | May 2002 | A1 |
20030101243 | Donahue et al. | May 2003 | A1 |
20040210450 | Atencio et al. | Oct 2004 | A1 |
20050027851 | McKeown et al. | Feb 2005 | A1 |
20050091313 | Zhou et al. | Apr 2005 | A1 |
20050163242 | Ungerboeck | Jul 2005 | A1 |
20050253722 | Droms et al. | Nov 2005 | A1 |
20060050862 | Shen et al. | Mar 2006 | A1 |
20060161636 | Huber et al. | Jul 2006 | A1 |
20060233171 | Murray et al. | Oct 2006 | A1 |
20060271707 | Cheline et al. | Nov 2006 | A1 |
20060274668 | Franklin et al. | Dec 2006 | A1 |
20070005950 | Backman | Jan 2007 | A1 |
20070022211 | Shimizu et al. | Jan 2007 | A1 |
20070022469 | Cooper et al. | Jan 2007 | A1 |
20070097860 | Rys et al. | May 2007 | A1 |
20080025299 | Agarwal et al. | Jan 2008 | A1 |
20080279116 | Tuffin et al. | Nov 2008 | A1 |
20090138476 | Zimler et al. | May 2009 | A1 |
Entry |
---|
S. Alexander and R. Droms, IETF RFC 1533, DHCP Options and BOOTP Vendor Extensions, Lachman Technology, Inc., and Bucknell University, Oct. 1993, pp. 1-30. |
M. Patrick, IETF RFC 3046, DHCP Relay Agent Information Option, Motorola BCS, Jan. 2001, pp. 1-14. |
Number | Date | Country | |
---|---|---|---|
20080056240 A1 | Mar 2008 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 11514679 | Sep 2006 | US |
Child | 11788780 | US |