CA2243668C - Architecture and method for managing a flexible communications network - Google Patents

Abstract

The present invention discloses an architecture and method for establishing one or more variable bandwidth communications channels that provides telecommunication customers with immediate setup of an arbitrary bandwidth connection upon demand. A centrally disposed access server (40) controls all of the switches (19) that form the traffic-bearing network (15) and forms a single portal through which all connection requests are made. Requests from users (12) and network applications are interpreted, validated, translated, and seamlessly delivered to the DXCs by the access server (40). The access server (40) comprises a packet switched data network (42), a processor (44), and several workstations (46, 48) for performing a plurality of customer and network related functions. The access server (40) functions as an intermediatory between a traffic-bearing network (15) and one or more network subsystems (20, 25) which are responsible for allocating the connection based on the customer's request.

Description

ARCHITECTURE AND MET~OD FOR
~TNG A FT.R~TR~.~ CO~ J~lCATIONS NETWORK

TECHNICAL FIEL~ OF THE I~V~:~llON

The present invention relates in general to an improved telecommunications system and more specifically to an architecture and method for providing efficient customer setup of an arbitrary bandwidth telecommunications connection upon ~m~n~, W O 98/18235 PCTrUS97119223 R~CKGROU~D OF T~ INrVENTION
The Public Switched Telephone Network (PSTN~ provides communication services to numerous subscribers. The PSTN i8 ,.
designed for intermittent use by each subscriber because it ~i i8 neither practical nor desirable to design a network to 4 maintain a constant connection among every possible pair of subscribers. Thus, subscribers effectively share the PSTN
by using it at different times and in limited portions of the overall available network bandwidth.
lU For typical connections, network resources neces6ary to complete an individual phone call are reserved at the time the call is originated by a calling party. In the telecommunications services industry, a typical subscriber connection consists o~ one or more telephone lines connected to a central o~fice. The central office, in turn, i8 connected to a plurality o~ network switches.
Other types of subscriber connections are often desired. For example, some customers may require semi-permanent connections between particular sites. In such a case, it is often more economical to bypass the central office and connect the sites to each other using a network switch. Such a connection is referred to as a dedicated private line.
A private line is a permanent connection within the network which joins a pair of distant customer sites.
Rather than being dialed through a central office to request a network ~h~nn~l, a purely private line is constantly reserved and available exclusively for a single customer's use.
In addition, customers that need to carry high bandwidth digital data cannot o~ten do so over a single conventional telephone channel. Because such signals are compatible with the high-speed multiplexed telephony signals commonly transported by telephone networks, such customers can use a direct T1 (1.5~4 Mbps~ digital connection to transport such high bandwidth digital data, voice or video.
In addition, customer re~uirements generally vary between single shared access telephone connections and wide bandwidth dedicated connections. In general, telecommunication subscribers have a spectrum of needs that lie between these two extremes.
For example, in terms of bandwidth, the needs of subscribers typically range from a single telephone voice channel (the equivalent of 64 Kbps) to a Tl line (1.544 Mbps), a ~3 line (44.736 Mbps), and beyond. In the interests of scaling services to economically meet customers~ individual needs, many options have been developed for allocating bandwidth incrementally. For example, fractional T1 services refer to bandwidth offerings in 64 Kbps increments. In this mAnn~r a sùbscriber does not have to pay for accessing an entire Tl transmission line, when they only require part of the bandwidth. The provider can sell the re~Ain~ng bandwidth to other such customers.

~VO 98/18235 PCTrUS97/19223 Variations in the time domain are possible as well.
For example, some customers may view constant availa~ility as a critical need, while others can tolerate call setup delays or occasional call blockages in ~avor of a less S expensive solution. Generally, a single telephone line connected to a central office makes a request for network resources whenever a phone call is initiated. I~ network resources are unavailable, the call is blocked. In contrast, a dedicated line is always connected and available. A compromise between these two extremes i8 a scheduled shared access line.
A subscriber such as a bank may need a constantly available T1 line for only two-hours every night at a particular time. Thus, the same T1 line can be made available to other subscribers at other times. The arrangement is more cost e~fective for everyone involved than buying ~ully dedicated T1 lines that are mostly idle.
To further improve such services, the telecommunications industry is developing techniques ~or what is known as Bandwidth On Demand (BOD). The goal of BOD
is to allow subscribers to instantaneously obtain as much network bandwidth as they need for however long they need it and to have service providers bill them accordingly for the time and bandwidth actually used. Currently, there a~e 2S several existing and planned techniques for accomplishing such types o~ ~lexible connections.

W O 98/18235 PCT~US97tl9223 One type o~ conventional ~lexible connection i~ a Tl line with 24 rhAnnels (at 64 Kbps each) each of which can be configured as an incoming or outgoing channel. Further, each channel can be configured for a particular type of service, such as a dedicated private line, 800 service, etc.. (depending on the cu~tomer). While such a method gives the customer a choice in available bandwidth, the connection typically requires several days or longer to be established by the ~ervice provider. Thus, an in~tant or on-~e~n~ connection cannot be established.
Another method gives the customer control of a terminal attached to the provider's equipment in order to reconfigure their communications line based on need. Examples o~ such services include the Digital Reconfiguration Service (DRS), Dynamic Allocation of Bandwidth (D~3), and Fixed Network Recon~iguration (FNR). These services require a considerable amount of mAnllAl intervention and advance planning by the customer prior to connection. Thus, an unsophisticated user cannot easily establish and control the co~ml]nications link.
The Integrated Systems Digital Network ( ISDN) o:Efer8 a digital subscriber connection with adequate bandwidth to carry several voice and data ~h~nn~l S simultaneously. The basic ISDN connection consists of 2 voice chAnnels and 1 data chAnnel while the primary ISDN connection consists o~
23 voice chAnn~ls and 1 data chAnnel. These services O 98118235 PCT~US97119223 feature fast call setup, moderate bandwidth ~up to the T1 rate) and dynamic flexible setup.
ISDN use, however, i8 limited Eor several reaqons ISDN services are not readily available in all areas.
Additionally, the e~uipment necessary to facilitate an ISDN
connection is typically too expensive for average applications.
Frame relay/cell relay techni~ues, most notably Asynchronous Transfer Mode (ATM), are expected to pervade the telecommunications market within a few years. These technologies appear promising but their implementation will require further work on standards and large-scale replacement of hardware throughout the network, thus such implementation will be costly.
Providing arbitrary bandwidth on-demand is problematic using existing network e~uipment in part, because digital cross connects (DXCs) typically support only a limited number of high-speed synchronous X.25 control lines, which are preferred for fast command response. It is desirable to implement a network control design that allows sharing of network control between multiple service-level and network-level applications. Such a design would readily accommodate new applications without an overhaul of existing applications.
Thus, a method and architecture that gives customers a wide range of network resources on an as-needed basi~ and bills the customer for that resource actually used would provide great advantages over other methoda of flexible bandwid~h connections.

W O98/1823~ ~lrJ~7/l9223 SU~ARY OF TH~ IN~J~TION
Accordingly, the present invention discloses an architecture and method for establishing one or more variable bandwidth communications ~h~nn~ls that provides telecommunication customers with immediate setup of an arbitrary bandwidth connection upon demand.
As such, it is a primary object of the present invention to provide a system architecture that allows a customer to obtain or schedule a connection of almost any bandwidth including DS0, T1, fractional T1, T3 and other bandwidth classes. Custo- mers can request a connection in a number of ways and expect setup times comparable with voice call setup time, that is, within a few seconds.
Another object of the present invention is to provide a system and method for billing customers according to actual use of network resources.
Still another object of the present invention i8 to provide an architecture wherein network features and services may be added without replacing applications on a widespread basis across the network and in a transparent manner to the customer. In this regard, a centralized access server controls the switches within the traffic-bearing network and functions as a single portal through which all connection requests are made. Requests from users and/or network applications (i.e. for restoration, capacity management, provisioning, etc.) are interpreted, validated, W O 98/18235 PCT~US97/19223 translated, and seamlessly delivered to the network digital cross connects (DXCs) by the access server.
Yet another object of the present in~ention is to provide an architecture that is resilient and capable of detecting faults along the transmission path and capable of rerouting the call should a fault be detected. The failover must be transparent to the customer.
An advantage of the present invention is that it allows telecommunication companies to offer ATM-like services well in advance of the availa~ility of such services. The technology used to implement the present invention is readily available and implemented using a modified version of existing e~uipment and protocols.
Another advantage of the present invention is the increased speed and ease in integrating new network applications because no single application monopolizes the cros~ connects links (DXC). The present approach also o~f-loads some of the processing requirements from the DXCs and thereby moves more of the feature implementation into the network control system.
Yet another advantage of the present invention is that DXCs from multiple vendor~s equipment can easily be supported by the translation capabilities within the access server.
Still another advantage of the present invention is its re~lln~nt distributed design which allows for fast, smooth cut over of the entire network to an alternate network controller during failure or maintenance events.
For a more complete understanding of the present invention, including its features and advantages, reference S is now made to the ~ollowing detailed description, taken in conjunction with the accompanying drawings.

-~0-W O 98/1823~ PCTrUS97/19223 R~T~ DESCRIPTION OF THE FIGURES
In the drawings:
Figure l i8 a block diagram of an architecture for establishing a flexible bandwidth connection according to one embodiment of the invention;
Figures 2A-2C illustrate the interconnections between a digital network ~upport system (DSS), the MegaHub Basi6 Controller ~MBC), the Digital Cross Connects (DXCs) and the common access server according to one aspect of the invention;
Figure 3 is a high level diagram of a communications architecture for flexible bandwidth management according to one embodiment of the invention;
Figure 4 illustrates the communications architecture between the DSS and the access server according to the invention;
Figure 5 i1lustrates the re~lln~ncy pathway architec-ture according to one configuration aspect of the invention;
Figure 6 illustrates the mapping of X.25 virtual ZO ~h~nnels between the acce~s server and other subsystems of the network;
Figure 7 is a process flow diagram of the method u6ed to handle network control messages according to the invention;
2S Figure 8 is a block diagram of the customer setup and provisioning functions according to one embodiment of the invention;

Figure 9 is a graphical user interface for a CVNM tool which may be used to select origination/destination city pairs for path connection.
Corresponding numerals re~er to corresponding parts in S the figures unless otherwiRe indicated.

W O 98118235 PCT~US97/19223 DETA~n DESCRIPTION OF THE lNV~N-llON
In part, the present invention is an improved telecommunications system and architecture that provides customers with immediate setup o~ an arbitrary bandwidth connection upon ~em~An~. A centrally disposed access server controls all o~ the switches that form the traf~ic-bearing network. The access ~erver is the single po~tal through which all connection reque~ts are made. Requests from users and network applications are interpreted, validated, translated, and seamlessly delivered to the DXCs by the acce~s server.
Referring now to Figure 1, a block diagram of a telecommunications network for flexible bandwidth management according to the preferred em~odiment of the invention is shown and denoted generally as 10. As illustrated, network 10 comprises an access server 40 that is centrally con~igured between the traffic-bearing network 15 and the Network Support System (NSS) 20, the Cross Connect Controller (CXC) 25 and some other network related functionality 30.
The traffic-bearing network 15 may comprise any one of the known and existing switched data networks capa~le of carrying signals of varying bandwidth and densities.
Examples include Public and Private Data Networks ~PDNs) t 2~ local ~chAnge networks and still others as is appreciated by those skilled in the art. Network 15 i8 shown to comprise numerous interconnected switching nodes 19 each of W O98/1823~ PCT~US97/19223 which has a control link 17 coupled to the access server 40 which, in turn, coordinates the delivery of switching comm~n~ within the entire traffic-bearing communications network 15. Likewise, network customers 12 have access to the switch network 15 via links 14.
The core of the access server 40 comprises a packet switched data network 42, a processor subsystem 44 and several workstations 46 and 48 and corresponding interfaces S0 and 52. In practice, the network 42 may be an X.25 packet switched network implemented using, for example, commercial off-the-shelf (COTS) routers like the DynaStar 200 manufactured by Dynatech Corporation.
In one embodiment, proces~or subsystem 44 comprises one or more Alpha processors made by Digital Equipment 1~ Corporation and has at least one communications link 43 coupled with the network 42. The processor subsystem 44 also has access to a database 54 for storing a variety of network related information to support the various functions. Examples include control link information, DXC
node type, switch, router and ch~nnel configuration information among other as would be appreciated by those skilled in the art.
Various subsystems that would normally exercise direct control over the traffic-bearing network 15 are represented 2~ by blocks 20, 25, and 30. In accordance with the present invention, these blocks 20, 2~, and 30 are COTS subsystems that have been modified as described below. In this regard, W O 98/18235 PCT~US97/19223 Figures 2A-2C illustrate the progression of control arrangements used to describe the modifications of the subsystems 20, 25, and 30, according to the pre~erred embodiment of the invention.
In Figure 2A, the provisioning ~ubsystem 20, preferably having a graphical user interface (GUI~ front-end, is shown connected directly to a traffic-bearing network 15 of switches, as depicted by the DXCs 70. The provisioning subsystem 20 can be a Digital Support System made by Prism Systems that is generally used as a network management system for monitoring the state of a network 15.
In accordance with the present invention, the NSS 20 is adapted to perform two functions. First, the modified NSS
20 provides a visual workstation from which to establish the end-to-end connection and ~m;n~ster customer privileges, according to the present invention. The second function performed by the modified NSS 20 is to provide a real-time, fine-grained view of the actual routing of traffic in response to connection requests. In addition, the NSS 20 2Q performs ~nh~nced network management functions for established calls.
Figure 2A al~3o shows CXC 25 which in one embodiment i8 a modified version of a MegaHub DEX 600E (MegaHub) switch ~ade by Digital Switch Corporation. The CXC 25 is used to accomplish u~age-based billing, alarm filtering, and centralized connection setup among other similar network control functions.

W O98118235 PCT~US97/19223 In accordance with the present lnvention, a MegaHub 25 is modified by replacing the internal switch fabric with X.25 control links to the network DXCs 70. In this manner, the modified MegaHub 25 handles the entire network 130 as if it were a single switch matrix. The MegaHub 25 so modified i8 referred to as the MegaHub BASiS Controller (MBC).
Various methods can be used to modify the internal switch fabric of the CXC 25. Speci~ic implementations of such modifications will be apparent to persons skilled in the relevant art.
The MBC 25 provides for a wide variety of methods to setup a connection. For example connections can be setup using Dual Tone Muiltifre~uency (DTMF), dial-up lines, dedicated lines, or in-band signaling methods. Other means contemplated ~or signaling connection setup include SS7, Internet and others which are apparent to those skilled in the art.
Regardless of how the CXC 25 is implemented, the subsystems 20 and 25 are conventionally applied separately.
That is, prior to the present invention, there has been neither a motivation nor a means for integrating the operation o~ these two types o~ subsystems, such as the subsystems 20 and 25.
Furthermore, a general technical barrier to such integration has existed in that each DXC 7~ generally supports a limited number of control links. In addition, it is common to use re~lln~nt connections from a given W O 98/18235 PCT~US97/19223 supervisory control subsystem to improve network reliability and increase robustness. Thus, conventionally it has been problematic to have multiple subsystems controlling a common set of network switches 15. However, for various reasons, ~ 5 it is desirable to have two or more subsystems, such as 20, 25 or 30 control a common set of network switches 15.
For example, the integration of the operation of subsystems 20 and 25 serve to solve a conventional problem associated with the field of network control that relates to addinq new functionality 30 to the network. Adding new functionality 30 generally involves modifying and adding software to both the DXCs 70 and the control elements such as 20 and 25, which are already driving existing applications. Thus, in order to add new functionality 30, several applications are ~orced to coexist within a single subsystem, such as the subsystem 20, because DXCs 70 are typically driven by a single supervisory subsystem.
However, as will be apparent, by sharing network control between multlple subsystems 20 and 25, new functionality 30 can be accommodated without an overhaul of prior software. For example, the application software for a new function can reside in any other subsystems 30 that have shared access to the DXCs 70. Thus, the integration of the two subsystems 20 and 25 is particularly advantageous.
Figure 2~ depicts an example of how the subsystems 20 and 25 can be further modified and applied to operate upon a common networ~ 15 in accordance with the present invention.

W O 98/18235 PCTrUS97/19223 As shown, the subsystems 20 and 25 are modified so that they communicate with each other. Within each subsystem 20 and 25, a communications process is added (20a and 25a, respectively).
~i In addition, two communication rh~nnels 72 and 74 are used to join the two subsystems 20 and 25. In a preferred embodiment, these communication ch~nnels 72, 74 take the form of an SS7 Transaction Capability Application Part (TCAP) message format to comply with prevalent standards although other ~ormats may also be used. In this m~nner~
the NSS 20 may send call setup in~ormation to the MBC 25.
The MBC 25, in turn, causes a connection to be formed within the network 15. Likewise, the MBC 25 can send unsolicited path change information to the NSS 20 so that the latter may maintain an up-to-date representation o~ what is connected within the traf~ic-bearing network 15 and perform real-time alarm and performance monitoring.
Various methods can be used to implement the communi-cation processes 2Oa and 2Ob and specific implementations of such modifications as described above, will be apparent to those skilled in the art.
Another modi~ication of subsystems 20 and 25 iB shown in Figure 2C wherein the packet switched connections 76 and 78 ~rom the subsystems 20 and 25, respectively, which are 2~ conventionally connected directly to DXC 70 control links, are instead connected into a common access server 40 according to the present invention. In this m~nnPr, both CA 02243668 l998-07-22 W O 98/18235 PCT~US97/19223 subsystems 20 and 25 may act upon a common set of switches in the traf~ic-bearing network 15.
It is a distinct advantage of the present invention that numerous subsystems, such as subsystems 20 and 25 and/or applications within such subsystems, may each act upon the network 15 without requiring an awareness or regard for one another. This feature is use~ul for providing fast, efficient, and simple integration of applications upon a common network 15.
Note that the interconnection of the two subsystems 20 and 25 as described above, via the direct connections 76 and 78 are accomplished via the common access server 40 as depicted by the PVC/SVC ~h~nnel 80. If the subsystem~ 76 and 78 were directly connected, as shown in Fig. 2B, the ~irst aspect o~ interoperability as described above can be practiced in the network 15 independently of the access server 40.
There is an additional practical benefit in using the access server 40 as an intermediate between the subsystems 20 and 25. The NSS 20 generally operates its packet switched links in a switched virtual call (SVC) mode. This means that a connection or session is established for each message that traverses the link. This is adequate for intermittent or low volume use where response time is not critical. On the other hand, the MBC 25 operates some of its packet-switched connections in a permanent virtual circuit (PVC) mode. In a PVC mode, a session is established -W O9~1823~ PCT~US97/19223 once and then used for all subsequent message communications.
The PVC mode is preferred for continuous, high-volume use when a session setup ~or each message would incur too much delay. Therefore, for practical reasons, the common access server 40 is al80 conveniently used as a platform for adapting between the mixture of SVC and PVC links that are prevalent in telecommunications hardware and applications.
Referring back to Figure 1, the NSS 20 and the MBC 25 are shown attached to the packet switched network 42 within the common access server 40 via links 22 and 27, respectively. Other subsystems, represented by the block 30, may similarly be connected to act upon the traffic-bearing network 15. In this mAnner~ new subsystems that are developed in the future, as well as legacy subsystems which customers use to exercise limited configuration and control, are easily accommodated by the network control system of the present invention.
As disclosed, the subsystem 20 may be implemented using Prism~s Digital Support System (DSS) which may ~e configured to perform various network management functions. While the functions and configuration settings of a DSS 2~ may vary, as is understood by those skilled in the art, the following description highlights various features of a DSS per one embodiment of the invention:

W O 98tl8235 PCT~US97/19223 DSS 20 SPECIFICATION. FEATURES AND FUNCTIONS ACCORDING TO
ONE ~BODIMENT

The DSS 20 can be implemented through a number of independent and yet operationally integrated software feature groups. DSS 20 monitors and correlates functions among the ~eature groups. A common application interface ensures all parts of DSS function as a single entity even if individual modules are installed at physically separated locations. With unified visibility on DSS 20, an operator can respond quickly without the need to perform tedious operational duties on duplicated hardware that would otherwise be required.
DSS-II APPLICATIONS
O~erator Workstation (OWS) Using a standard OSF/Motif compatible X-terminal or workstation with a TCP/IP interface, an operator can log on from any location and simultaneously access different applications o~ DSS 20 or any other X-window compatible OSS
through point-and-click interactions.
Event Logging (ELS) DSS 20 allows customization of event log displays on an ad hoc basis according to operator instructions. Users can obtain precise and quick isolation of real-time and 2~ historical information. An operator can categorize events by equipment and transmission facilities along with alarm severity. New alarms a~e highlighted for quick review until they are acknowledged. In this way, an operator can easily W O 98/18235 P~l/u~7/l9223 identify potential network problems or any log on attempts by unauthorized personnel.
Sexvice Inventory Manaqement (SIS) An intelligent Ingres relational database management ~ystem is employed in DSS 20 to improve user querying o~ the inventory system. Key inventory information such as circuits, equipment and customer information are synchronized with other DSS feature groups, thus allowing better management of the network with consistent and updated information. In addition, the inventory database correlates bandwidth and path objects with customer data to provide virtual network management.
~plication Management (APM) DSS 20 operates on a scalable L~N architecture. DSS 20 can monitor feature groups which are distributed across multiple host systems and, if so equipped, to prevent a total ~ailure. DSS 20 can maintain standby copies of each software module on optional redundant host hardware such that an application can be quickly restored upon primary failure or during hardware/so~tware upgrade. Database information can be maintained simultaneously on multiple hardware systems to ensure configuration integrity.
~onnect;vlty Management tlM~) DSS 20 employs connectivity management software which supports creation, removal, non-contending bandwidth allocation and pre-plan restoration of end-to-end DS0, nxDS0 and DSl circuits. A central and unique :Eeature i5 Customer W O 98/18235 rCT~US97/19223 Virtual Network Management (CVNM) which provides fine-grained partitioning of ~andwidth based on customer identifler.
Customer Network status Display DSS 20 correlates with the inventory database and the event log system to support graphical 5tatus display of a customer virtual network on an indu~try standard PC. This feature i8 used in the provisioning of customer services.
External SyRtem Interface (ESI) Integrated access to DSS 20 from embedded Order Entry and Provisioning systems can be developed based on an external system inter~ace. The integration of DSs 20 with existing or upcoming operational support systems eliminates system boundaries and duplica~ed hardware to provide a more efficient operation.
~S1 Management In one embodiment, a total of six (6) Sun SPARC 10 servers are used wherein four (4) of these are SPARC 10 model 51's that are configured for host applications. The remA~n;ng two are SPA~C 10 40's that are configured for communication processing. Two (2) of the four (4) application servers (Type Al) are configured for database applications, and each equipped with 256 MB memory as well as 6.3 GB disk. The other two (2) (Type A2) are con~igured 2~ for other applications, and each equipped with 256 MB memory and 4.2 GB disk. Resilient operation will be provided, with W O98/18235 PCT~US97/19223 an active and a standby copy of the Ingres RDBMS and each application ~ubsystem deployed among the four servers.
The communication servers ~upport network element communications. Each sy~tem is equipped with 224 MB memory and 2.1 GB disk. The host systems communicate to the network ele~ents on X.25. This is achieved b~ a synchronous RS-449 ports on the servers.
Also, in one embodiment, five (5) Sun SPARC LX
workstations provide the user interface for database management, system admini~tration, and other usage where system response is important. All servers and workstations may be interconnected via an Ethernet LAN system, with TCP/IP communication.
An NSD/PC terminal allow~ a CVNM customer to monitor his dedicated network from a personal computer at the customer premises. Each of the four ~4) application ~ervers ha~ eight (8) asynchronous ports for text terminal, printer, NSD/PC and other peripherals.
C~S1 P~th PrDv~ s;oning DSS 20 supports definition of DSl rate paths in the DS1 network. In this regard, DS1 paths are transported through the network on any hardware compatible 1/0 DCS switched facility.
DSS 20 ~upports definition o~ DS0 and n*DS0 rate paths in the DS1 network. DS0 paths are tran~ported through the network on any 1/0 DCS switched facility. The DSS
administers signaling for voice and data paths.

, W O 98/18235 PCT~US97/19223 DDS Path Provision, ng DSS 20 supports the definition of 2400, 4800, 9600 and 56000 bps DDS paths in the DSl network. These paths may be transported through the network on any l/0 DCS switched S facility. Additionally, DSS 20 supports the subrate multiplexing of these circuits at any l/0 DCS suitably equipped for the operation.
Multipoint Path Provisio~g DSS 20 supports definition of DDS MJU and data polling DMB path~ in the DSl network. DSO paths may be transported through the network on any l/0 DCS switched facility.
Internal cascading of multipoint circuits will only be supported for MJU circuits. Other types of multipoint circuits are not supported, including peer to peer symmetrical bridging.
Bandwidth Part;tioning DSS 20 partitions DSO bandwidth based on customer identifier. Bandwidth associated with a specific customer identifier may only be used in paths defined for that customer. The allocation of bandwidth in this manner is typically performed by telco users. Specific users may be assigned the privilege of using pre-assigned Bandwidth On Demand (BOD) pools during path definitions. The privileged telco user is responsible for assignment of bandwidth. This includes Bandwidth on Demand (BOD) pools.
Cl~tomer Partitioning W O 98118Z35 PCT~US97/19223 DSS 20 supports information partitioning in specific DSS operations based on the customer' 8 defined virtual network. For e~ample, query operations can be restricted based on customer identifier.
p~rt~t;on Security r DSS 20 enforces the virtual network partitions and prevent unauthorized users from 5eeing across the partition boundaries within lMS, ALS and ELS applications. DSS 20 provides a user specific profile, controlled by the system administrator, that specify valid customer IDs for the user and assign privileges to perform DSS operations on a per command basis.
Randwidth On Demand DSS allows DSO bandwidth to be associated with specific bandwidth on demand (BOD) pools. Specific users are granted access to specific BOD pools for path definition. BOD
bandwidth is returned to the BOD pool when the user discontinues its use (ie. schedule completes and path is removed from service). Typically, BOD pools are setup by telco users and CVNM users ~chedule DOD use of specific amounts of bandwidth.
Partitioned ~larm Display DSS provides a customer partitioned display of facility alarm events affecting a customer virtual network.
25- Pl~tform DSS software executes under the UNIX operating system.

W O 98/18235 PCTrUS97/19223 In one e~bodiment, on a SuN 4 platform u~ing sUNos (Solaris l) is used although other X-Window~ compliant workstations may be used. A database system, such as the INGRES RDBMS, may be installed on the DSS platform. DSS 20 ~hall require S that VI Corpis DataViews be installed on the DSS platform.
DSS 20 may be installed on a multiple SUN 4 computer platform co-re~ident on an ethernet LAN.
Site Resilience DSS applications provide reliable operation in a distributed non fault-tolerant multi-proce~50r platform.
Each DSS application can be constructed with a common Remote Procedure Call (RPC) ba~ed inter-proces~ communication API
that enables a client-~erver application architecture.
Application client components locate ~transparently to the user) their corresponding active server components upon start up and behave gracefully in the ~ace of non client (ie LAN, server platform, server application) DSS outages.
Eligible application server components have at least one active instance and one standby instance on different computers in the platform. Change over to the standby instance of any server is controlled by the application manager.
The time for each DSS application to change over to the standby in~tance is application specific. Typically, an application shall change over in under 15 minutes. DSS
application components can be deployed on any of the W O98/18235 PCTrUS97/19223 computers of the platform to achieve improved performance and reliability.
DBMS
In one embodiment, Ingres relational DBMS is used for storage of the network management inventory information.
ANSI standard SQL is used by DSS software to access these inventories. Also, in another embodiment, DSS 20 uses the Raima DBMS product (formerly called DBVista) for storage of DSS internal events and network generated events.
Data Comml~nications In one embodiment, DSS 20 is configured with two Sun SPARC 10 communications engines to support initial efforts to control approximately 86 DSC DEX CSLL nodes as well as interconnecting the DSS and MBC-2 systems. DSS communicates 1~ through access server(s) designed to interface to each system's native X.25 links and route X.25 virtual channels serving the different applications.
Each DSS communications system runs Sl~nT.; nk X. 25 communications software and supports 2 four-port ~SI cards that plug into the system SBUS. Each port supports an RS-449 physical interface.
Each DSS communications server supports a minimum of two (2) HSI cards supporting 4 ports each. At least one more can be added to each server as needed. Depending on the number of spare SBUS slots, more HSI cards may be added to each server.

W O 98/18235 PCT~US97/19223 Each DSS communications supports a minimum of four (4) 56 Kbps X.25 links. This allows the DSS 200 to use a pool 8 physical link8 with 256 channels per link to establish any virtual control channel.
The DSS 20 automatically e~tablishes Switched Virtual Circuits (SVCS) to any defined DXC and MBC channels. If an SVC ~ails, the server will attempt to re-establish it. I~
the physical 56 K~ps link fails, all ses8ions on that link will be restarted on other physical links. In one embodiment, each DSS communications supports a minimum of 256 Switched Virtual Circuits (SVCS) per X.25 physical link allowing up to 1024 SV~s per communications server.
Additional communications servers can be added easily to support larger link capacity and throughput re~uirements.
Thus, the DSS communications system is scalable and can grow as needed to support additional nodes, higher throughput and per~ormance.
Metho~ of O~e~at;on In the pre~erred embodiment of the invention, DSS 20 supports remotely routed circuits which are tracked within the database as described above. A CVNM tool will extract from the SOT a node name; the node must be a multiplexer.
Also, if the node type is valid the DSS 20 will prepare a list of 10-digit MBC ports defined at that node. This list will only show those ports for which the user's profile allows (e.g ports for other customers will not be displayed). The CVNM tool will allow the user to select a W O98118235 PCT~US97/19223 single 10-digit port per node. Two nodes are required to be selected - one for the originating and one for the terminating end of the circuit.
The user can select a node in a variety of ways. Using the ALS, the user could click on the node. Nodes are not displayed on the user's ALS screen i~ no circuits for their profile have defined. Users can also select nodes via the SOT lookup method or via the SIS. When both nodes have been selected and their ports selected the user will be presented with the option of placing the circuit into service or removing from service immediately. If a circuit i8 placed into service then the circuit record will automatically generated via the path generation software described above within a short period of time.
The list of 10-digit ports available at the node will be selected from the database each time the user selected a node. Thus, the user does not need to maintain his own copy of the 10-digit ports available to the user.
The access server 40 also drives a number of inter~aces other than the subsystems 20, 25 and 30, and the traffic-bearing network 15. In particular, as shown in Figure l, a configuration workstation 46 is shown connected to processor 44 for the purpose of allowing network personnel to view or assert information about what subsystems 20, 25 and 30 and other network elements connected to the access server 40.
This information is stored in the database 54 and may W O 98/18235 PCTrUS97/19223 further include the capabilities and protocols appropriate to each entity attached via packet switched network 42.
The status/history workstation 48 is also shown coupled to the processor 44 for the purpose of displaying the S operational state of the packet switched network 42 and all links connected thereto. This status/alarm monitoring can encompass all software applications, hardware devices, and router ports in the realm of the access server 40.
The application block 56 in Figure 1, represent~ a functionality, such as a software process or the like, that can act directly through the access server 40. One of the uses contemplated for such an application 56 are uploading/
downloading operating software, database contentRl co~m~n~
and status indicators, to and from the traffic-bearing network switches 15.
The remote interface block 58 represents a connection that allows remote processes to access many of the same functions within the acces~ server 40 as are provided through workstations 46, 48 or application 56. Thus, remote control and monitoring of the network controller can be accomplished.
Those skilled in the art will immediately appreciate that various implementations of the acce~s server 40 may be achieved. The following description of the access server 40 conforms to one contemplated embodiment and highlights, without limitations, various aspects of an acces~ server according to one embodiment:

ACCESS S~ D~CRIPTION ~ND F~NCTION}~T SPECIFICATION
ACCO~ING TO ON~ ~MRODIMENT
The objective of the access 8erver 40 i5 to route messages through virtual channels using X.25 concentrator devices and low level X.25 router eguipment without introducing any delay in the end to end message path. In this regard, most of the virtual ~h~nnel8 (see Figure 6) are routed through the access server 40 point to point and do not re~uire any processing other than routing. This routing can be handled completely by the X.25 communications servers and do not require any system CPU utilization. ~imiting message delay is most critical in the routing and processing of the DXC binary message6.
Thus, in the preferred embodiment the access server 40 introduces nearly zero delay in any end to end virtual message path that does not require additional application processing. ~ikewise, the access server 40 introduces no more than a 100 millisecond delay to the end to end message path~ that require application processing such a~ database updates and message logging. This re~uirement applies specifically to the binary and ASCII connection and disconnection control ~h~nnels.
The access server 40 supports a minimum of 120 DXC
nodes and may be expanded to add additional DXC nodes as needed. The access server 40 continuously monitor~ all X.25 physical links and ~irtual channels and report alarms to a Network Management System (NMS) when a failure occurs.

W O 98/18235 PCT~US97/19223 A major alarm shall be reported when a single link failure is detected and a critical is reported when both (redundant) link failures are detected. Alarm idle messages are reported when link connectivity is restored.
The access server 40 periodically attempts to restart any virtual ~h~nnel8 that have failed. The interval for the periodic retry shall be configurable by the administrator ensuring that once a physical failure has been corrected that further manual intervention is not necessary to restore the communications channel.

Operational Requirements The access server 40 system software consists of operating system services which provide the ~ackground for the other application software layers. These services include the following:
- System Security Services System Management Services The access server 40 provides a means to ensure the protection of the system from unauthorized access or inter~erence.
- System backup and restoral facilities.
For disk and magnetic tape operations, the operating system software provides for device control for disk, tape and print device formatting, and mounting.
- Management of disk space, purging, sizing and process quotas.
- Tools ~or analyzing disk and magnetic tape errors.

W O 98/18235 PCT~US97/19223 - Batch and print operations managing process queues and jobs.
- Maintaining system log files and providing dump file analysis.
- Sy~tem generation and boot process - Installing device drivers, shared memory segments and processes.
- Monitoring and management of system performance.
- Application software scheduling and monitoring The access server 40 maintains statistical information (e.g. failure counts, retry attempts) for each external interface link ena~ling users to monitor link performance and view link status.
Sy~tem Inter~ace Requirements The access server 40 adapts to the native physical interface of each external system connected to it. Each of the external systems that the server communicates with are existing systems and have their own specific physical interface requirements. The access serVer 40 accommodates each native interface and requires no development to any of the external systems in order to communicate through the access server.
The access server 40 supports the following physical data communications interfaces to the specified systems:
X.25 SVCs - DSS-II
X.25 PVCs - MBC-2 (DXC and TCAP links) X.25 SVCs - DRS
X.25 SVCS - DSC DEX CSLL DXCs TCP/IP - Billing System Ethernet - NMS

W O98/18235 PCTrUS97/19223 Ethernet - Access Server The access server 40 supports the routing of the following communications protocols:
. DSC Binary DXC protocol t . PDS Snyder ASCII protocol TCP/IP
Decnet . X.25 The access server 40 provldes the routing of message traffic needed to support the integration o~ component systems enabling the following data flow~:
System Message Type DSS-II c --- > MBC-2 Binary SS7 TCAP messages DSS-II c --- ~ DSC 1/0 DXCs ASCII PDS messages D~S c --- ~ DSC 1/0 DXCs ASCII PDS meSSage3 MBC-2 c --- ~ DSC 1/0 DXCB Binary DXC messages Server c --- ~ NMS System alarm messages Server c ~ Billing Call Detail Records DSS 20 Interface Requirements The DSS 20 system is configured with two Sun SPARC 10 communications engines to support DSC DEX CSIL nodes as well as interconnecting the DSS 20 and MBC-2 systems. DSS 20 will communicate through the access server 40 designed to interface to each system' 5 native X.25 links.
Because of the duplicated nature of the platform components, the DSS 20 communications are directly connected W O 98/18235 PCT~US97/19223 to each access servers (see Figure 3 and 5), one collocated and one distant.
The access server 40 provides physical link re~lln~ncy (see Figure 5) and routing of the virtual channels (see Figure 6) towards the network DXCs and MBC-2 systems. DSS
20 will monitor link failures and report loss of communications.
Each access server 40 supports a minimum of four (g) 56 Kbps X.25 DSS-II control links. This allows the DSS
~0 20 to use a pool of 8 physical links with 256 channels per link to establish any virtual control channel to the DXCs and MBC-2 systems.
Each access server 40 supports a minimum of 256 Switched Virtual Circuits (SVCS) per DSS-II X. 25 physical link allowing up to 1024 SVCs per DSS-II communications server. The access server 40 supports a CCITT compliant X.25 communications stack and performs the function of a standard Packet Switching Data Network ( PSDN). No proprietary Q-bit session layer manipulation i9 re~uired to interface to the DSS-II communications subsystem.
In one embodiment, the access server 40 allows 4 SVCs per DXC node from the DSS-II to be routed to 4 DXC ASCII
SVCs controlled by the access server 40 and allows a minimum of 2 SVCs to be routed from the DSS-II to the MBC-2 TCAP
25 - gateway interface PVCs.
Turning to Figure 3, a high level block diagram of an integrated bandwidth allocation system according to the W O 98/18235 PCT~US97119223 invention is shown and denoted generally as 100. In particular, dual and redundant systems 102, 104 are provided which allow crossover operation of each system for the entire network.
With respect to the left side 102, Figure 3 illustrates that customer premise e~uipment (CPE) 105 is used to gain access to the digital reconfiguration service (DRS) processor 109 via access terminal 107. As is known in the art, DRS is a network management system application that is designed to recon~igure a customer's portion o~ the connection and to con~igure temporary bandwidth when the customer needs additional capacity.
As shown by Figure 3, the left side 102 has a DRS
processor 109 are communicably linked to an access server 113 which provides various channel concentrating and routing functions as herein described. In one e~bodiment, access server 113 and its re~un~nt counterpart 115 comprise X.25 router equipment and DEC Alpha Processors which provide shared access to the network 111.
Redundant access servers 113 and 115 are communicably coupled to each other via links 114 and 116. Likewise, the access servers 113 and 115 are linked to the customer management service (CMS) processor 117 via control links 119. The CMS platform 117 is an entryway into various 2~ customer-related features and functions, such as customer orders, partitioning, message routing and other similar and related customer-related operations.

W O 98/lX235 PCTrUS97/19223 Turning now to Figure 4, the architectural interface between the Digital Network Support S~tem (equivalent to DSS 20 in Figure 1) 155 and access servers 159, 161 is hown. Figure 4 shows that a plurality of application servers 155, which collectively form an operable DSS, are provided upon which the various system wide applications are executed. Server operations include provisioning of end-to-end circuits, static or dynamic route selection, scheduled circuit recon~iguration, monitoring of network performance, partitioning of network resources, multi-level security access, multi-vendor support, disaster recovery and alarm management, customer virtual network management, graphic display of network status and interactive or batch proce~ing of command files among others.
A~ shown, the application servers 155 are communicably linked via LAN link 157 to communication servers 159 and 161 which, in turn, provide the control and command paths to access servers 163 and 165. In this regard, servers 163 and 165 are the functional equivalent of access server 40 of Figure 1 as previously described.
In one embodiment, each access server 163 and 165 supports a minimum of four (4) control links. Thus, each access server 163 and 165 can route X.25 virtual channel concentrating and routing functions to the application servers 155. The communications pathway is provided by communications servers 159 and 161 and link 157 which in one embodiment is a TCP/IP ch~nn~l.

W O 98/18235 PCTrUS97/19223 Each acces~ server 163, 165 supports a CCITT compliant X.25 communications stack and performs the ~unction of a standard packet switch data network. In this way, the access servers 163 and 1~5 can allow various SVCs per DXC
node from the application servers 155 to be routed to DXC
ASCII SVCs controlled by the access servers. In short, the access servers 163 and 165 form a transmissive non-interruptive control path between the data tra~ic-bearing network 15 and the network support system in place.
Turning now to Figure 5, a communications architecture 200 illust~ating the re~lln~ncy ~eature according to one embodiment of the invention as shown. The goal of architecture 200 is to provide high reliability to redundant paths between the various applications and DXCs in the network. As illustrated in Figure 5, 2 MBC processors 205 and 207 are communicably linked to one another via signal link 209. This provides dual and independent network controllers which can each separately operate and handle the whole load of the entire network should one side of the network control systems experience a catastrophic failure in e~uipment.
As shown, remote switches 211 and 213 provide physical links to opposite sides of the network control systems and give each side the ability to switch over should a fault occur. The switch layer 215 couples the MBC processors 20 and 207 to access service layer 217 which comprises a plurality o~ packets switch data components including W O98/18235 PCTrUS97/19223 concentrators 230 and access servers 233. A wide area network 219 is interspersed between the respective sides o~
the architectural system 200 providing a communications path at the server level 217. Finally, the digital cross connect layer 250 provides the link to the corresponding data traffic network.
As stated, one purpose ~or the access server 40 is to route system wide messages through virtual ch~nnels using X.25 concentrator devices and low level X.25 router eguipment (layer 217) without introducing any delay in the end-to-end message path. In this regard and according to one embodiment, most of the virtual channels routed through the access server are point-to-point and not requiring any processing other than routing. This routing can be handled lS completely by the X.25 communications servers (159 and 161 of Figure 4), thus not requiring any further access server utilization. The access server layer 217 must intercept digital cross connect connection messages ~rom layer 250 and determine connection status, deliver responses and queue them ~or update processing.
In short, Figure 5 depicts a high degree of redundancy among various processors and connecting links. In particular, a primary level of redundancy is a~forded by the Tl links between the left and right halves of Figure 5. A
secondary level o~ protection among access server processors of layer 217 is provided by the WAN 219. Finally, the X.25 W O 98/18235 PCT~US97/19223 routers 230 are extensively cross-connected 80 that a :Eailed router or link can be readily bypassed.
This design assure~ a highly robust architecture ~or distributing control information to the DXC layer 280 In fact, the system iB designed to allow two (or more~ MBCs 205 and 207 to control a network. As an important advantage o~
the present invention, these MBCs 205 and 207 may be geographical separated so that, in the event of a catastrophic failure of one MBC, control of the entire network can readily be assumed by the other MBC without any service disruptions. In Figure 5, SS7 signaling links 209 are shown connecting the two MBCs 205 and 207. This is done to maintain an accurate database of the state of the network at both locations.
Turning now to Figure 6, the mapping o~ the various X.25 virtual channels between each access server 159 and 161 and other network subsystems is shown and denoted generally as 275. Figure 6 shows the device virtual channels 280 which are routed to the access server side 285 on a point-to-point basis eliminating unnecessary delays. In one embodiment, the access server side 285 introduces no more than a 100 millisecond delay to the end-to-end message path that re~uires application processing such as data base updates and message logging. This requirement applies speci~ically to the binary and ASCII connection and disconnection control channels.

W O 98/18235 PCTrUSg7119223 In another embodiment, the access server side 285 is designed to support a minimum of 120 DXC nodes and may be expanded ko add other nodes as needed. In this regard, it should be understood that the access server side 285 of S Figure 6 illustrates the signal pathway traf~ic incoming and outgoing the physical access server 40 in ~igure 1 as well as redundant access servers 113 and 115 of Figure 3.
Other virtual channels between DSS 290, D~S 295, DXC
300, DXC manager 305 and TCAP gateway 310 are illustrated showing virtual channel paths and link designations according to the contemplated embodiment.
Access server side 285 provides the routing of message traffic needed to support the integration of various network wide components according to a set routing process which is 1~ denoted in Figure 7 as 300. Process 300 with ~tep 305 when the access server initializes the various links to determine whether the links are active and operational.
Next, in step 310 the access server ~m~ ne8 the status o~ the various virtual ch~nnel connections and reports the status to the network support system. At this point, the access server waits to receive the message along the link, step 315, and veri~ies the validity of any messages to assure an appropriate command or control is being sent, step 320. As shown, as long as a message is not received, 2~ process is directed to step 317 to examining the status of the various links across the network.

, W O 98tl8235 PCTrUS97tl9223 When a valid message is received, process ~low is directed to step 330 wherein the acce~s server collects the message source and designation input and looks up any translation o~ instructions specific to the message received, step 330. Mext, in step 335 the message i~
interpreted and transformed as needed and a route is selected to determine the best way to send the message to its intended destination, step 340. The mes~age is sent and when sent successfully process ~low is directed to step 317 wherein the access server reevaluates the statu~ of all links waiting for the messages.
On the other hand, where a message is not successfully sent and all pos6ible routes have been exhausted, step 350, and a rejection message is sent, step 355, to the message source and the command or message transfer iB aborted.
Should other routes be available, in step 355 the access server looks for other links and selectS the best route for the intended destination, step 340. This evaluation may involve testing for protocol adherence, access privilege, valid destination references and other qualifiers as is appreciated by those skilled in the art.
Turning now to Figure 8, the method of selecting a ~lexible bandwidth resource is shown and denoted generally as 375. Process 375 starts when a customer or service provider places an order for a bandwidth resource 380 which, in turn, is routed through a circuit provisioning process 385. In the preferred embodiment, the order is W O 98118235 PCT~US97/19223 instantaneously transferred to the circuit provisioning process 385 allowing an on-demand selection to be made.
Next, the customer order is directed towards a provisioning system 390 which receives the request in real time and updates the appropriate customer services data bases to ensure the customer has the authority and access to the requested bandwidth resource. If so, process flow is directed toward step 395 wherein the call and billing records are set up by the network using the appropriate control links. Also, network maintenance may be required 400 to assure correct signaling of the point-to-point connection as well as the quality of the link.
Finally, process 375 is directed to setting up the call 405 which establishes the connection and gives the customer exclusi~e use of the end-to-end transmission channel at the requested time and bandwidth.
Turning now to Figure 9, a screen 425 front end graphical user interface for a connection set-up utility is shown. Screen 425 may be used by a telecommunications customer or other user to set up a point-to-point communications channel which will enable a connection between any two points on the network. For example, the customer could use screen 425 to set up a communications link at a given time and date and for a given duration assuming the customer has authority to use the service. In this way, a customer can configure a high speed data transfex between any two points on the network, such as a WO 98/18235 P~~ 7/19223 video con~erence, a remote data bases search or other 6imilar unscheduled, high performance data trans~er.
As shown, screen 425 is split into a left side 430 and a right side 435 which in one embodiment correspond to S origination and terminating-points for the connection. On the origination side 430 a customer is given the choice of various locations ~rom which to originate the call. A
unique ten digit identifier and description field 434 is provided corresponding to each available origination site.
Li~ewise, a menu 437 of available for destination points on the right side 435 of screen 425 which allows the user to select from a plurality of available terminating points for the call. As shown, each terminating point has a ~our digit identifier and description 439, corresponding to end points on the call connection path. A confirmation box 440 is provided allowing the customer to configure the end-to-end path for the connection used using the speci~ied service and at a specified time and/or date. It should be readily understood that screen 425 i8 illustrative of one of many possible embodiments and that the features illustrated encompass one of many possible solutions to the same problem.
While this invention has been described in reference to illustrative embodiments, the description is not intended to be constr~ed in a limiting sense. Various modifications and combinations of the illustrative embodiments as well as other embodiments of the invention will become apparent to W O 98/1823S PCT~US97/19223 persons skilled in the art upon reference or description.
It is, therefore, intended that the appended claims encompass any such modifications or embodiments.

Claims (12)

What is claimed is:

1. A network architecture for establishing variable bandwidth communication channels upon demand, said architecture comprising:
a traffic-bearing network having a plurality of nodes linked to each other via a plurality of transmission paths, said nodes forming local hubs connecting a plurality of end users;
an access server coupled to said traffic-bearing network via a first plurality of communications links for receiving messages from said end users; and a network support system communicably linked to said access server via a second plurality of communications links, said network support system configured to perform a plurality of network management functions.

2. The architecture of Claim 1 wherein said access server further comprises:
a packet switched data network coupled to said first plurality of communications links for receiving messages from said end users;
a processor subsystem communicably linked to said data network;
a database coupled to said processor and storing a plurality of end user and network related information; and a group of workstations configured to provide a plurality of network configuration functions and status/history functions, said workstations communicably linked to said processor.

3. The architecture of Claim 1 wherein said network support system further comprises an application for initiating call setups and administering customer privileges.

4. The architecture of Claim 3 wherein said network support system further comprises an application for obtaining a near real-time view of network routing traffic in response to connection requests.

5. The architecture of Claim 1 further including a cross connect controller communicably linked to said access server via said second plurality of communication links.

6. The architecture of Claim 5 further comprising communications channels coupling said cross connect controller and said network support system.

7. The architecture of Claim 5 further including a plurality of switched X.25 virtual circuits forming a signal path between said access server and other subsystems of said network architecture.

8. The architecture of Claim 2 wherein said packet switched data network include a plurality of X.25 concentrators and low level X.25 routers for transmitting X.25 formatted messages along said network architecture.

9. The architecture of Claim 7 wherein the access controller introduces a near zero delay into the X.25 virtual circuit message paths.

10. A central access server for establishing a point-to-point communications channel in a telecommunications network said network comprising at least one traffic-bearing switched network, one network subsystem for provisioning available network resources and one cross connect controller, said access server comprising:
a packet switched data network communicably linked to both said telecommunications network and said network subsystems via a plurality of switched virtual circuits;
a processor subsystem coupled to said packet switched data network via a first communications link supporting a switched data protocol for receiving said messages originating from said telecommunications network;
a group of workstations linked to said processor subsystem and containing a plurality of network related applications for performing network related functions; and a database structure coupled to said processor for storing a plurality of network related information.

11. The central access server of Claim 10 further including:
an application program for uploading or downloading operating software, database contents, commands, and status indicators to and from said traffic-bearing switched network; and a remote interface that provides access to functions within said access server, said functions provided by either said workstations or said application program.

12. In a telecommunications network having an access server centrally configured between a traffic-bearing network and a plurality of network subsystems which control the provisioning and switching of available network resource, a method of allocating available bandwidth on the network comprising the steps of:
sending a user request for a telecommunications service;
intercepting the request at the access server level;
interpreting the request to determine the type of service requested by the user;
formatting the request according the a predetermined format compatible with said provisioning subsystem;
transmitting the formatted request to said provisioning subsystem;
determining if the user has authority to access the specified service; and allocating enough network bandwidth to accommodate the request.