CA2206616A1 - Centralized call control in a data access transport service - Google Patents

Abstract

In a Data Access Transport Service (DATS) wherein Data Service Providers (DSPs) share dial-in access (e.g.
analog modem or Integrated Services Digital Network (ISDN) access) resources from a common pool maintained by a Local Exchange Carrier (LEC) (or potentially a DSP), each DATS subscribed DSP's virtual resources must have high availability. A system is disclosed wherein an Internet Protocol Data Call Control server (hereinafter referred to as a "Network Controller" (NC) ) performs the role of DSP
service partitioning, quota enforcement, and resource load balancing to ensure that a DATS provider DSP can provide a high quality of service (availability, response time &
consistent bandwidth) to subscribed DSPs and their end-users. The Network Controller will assist in the Internet Data call establishment and tear-down, with the ability to refuse calls when the associated DSP has exceeded its service quota. The network controller will also assist in the routing of calls to one of the DSP's Network Gateways (or data routers), using a load balancing scheme that maintains a pre-defined relative load on given DSP Network Gateways. The Network Controller will also provide an implementation that supports Multilink Point-toPoint Protocol (MLP) and 56 kbps data calls for ISDN BRI access.
Additionally, the Network Controller will perform such functions as statistics collection, and network element administrative control. Finally, the Network Controller can be positioned to provide similar service control functionality with higher speed access technologies such as Assymetric Digital Subscriber Loop (ADSL) and high-speed cable modems.

Description

CA 02206616 1997-0~-30 CENTRALIZED CALL CONTROL IN A DATA ACCESS TRANSPORT SERVICE
Field Of The Invention The present invention relates generally to data communications network access and, more particularly, to Internet Protocol based services, dial-in data network access, data network transport, and Virtual Private Dial-in Networks.
Backaround Of The Invention Current data dial-in services exist today which permit end-users to connect their Personal Computers (PCs) to a Data Service Provider (DSP). The DSP provides end-users with access to the Global Internet, and, in the case of Corporate DSPs, access to corporate intranets.
Traditionally, connectivity between end-user PCs and a DSP is achieved through the use of a PC modem, which sends packetized data by modulating an analog signal. The modem uses the Public Switched Telephone Network (PSTN) to achieve connectivity to a corresponding DSP-owned modem in a modem pool, which de-modulates the signal and routes the packetized data to the appropriate destination, based on the control information imbedded in the data packet. End-user authetication, authorization, and accounting is performed by the ISP via standard techniques such as clear text password authentication, Password Authentication Protocol (PAP), or Challenge Handshake Authentication Protocol (CHAP). Once an end-user has been authenticated as a valid user, the end-user's data packets are sent to the appropriate destination (depending on the data packet's destination address), allowing the end-user to utilize data networking applications such as telnet, electronic mail, File Transfer Protocol (FTP), and Hyper-Text Markup Language (HTML) applications.
This arrangement has led to some problems.
Network studies have shown that a typical end-user dial-in data session lasts for twenty minutes, and that some sessions would remain active for hours or days. These large duration data calls can cause PSTN congestion, which CA 02206616 1997-0~-30 is engineered for voice calls which are typically three to five minutes in duration. PSTN congestion results in the added cost to LECs in regrading voice switches, and provisioning additional inter-office facilities (IOF) to handle the added load between voice switches.
From the DSP perspective, dial-in data services have created a different set of problems. The cost of maintaining modem pools contributes to a large percentage of a DSP's operating costs. Additionally, increasing modem pool capacity requires new access lines (either single access lines or multiplexed facilities such as Primary Rate Interface ISDN or channelized T1), which requiring significant lead-time for the LEC to install, making it difficult for a DSP from reacting quickly to increasing market needs in a timely fashion.
As a solution to these problems, Local Exchange Carriers (LECs) and some Large DSPs have begun to investigate alternative connectivity options allowing end-users to access the internet or corporate intranet. These service providers create a Data Access Transport Service (DATS) through which DSPs, who subscribe to the DATS, outsource their ISDN Basic Rate Interface ~BRI) and analog modem pools to an LEC or DSP (herinafter, for simplicity, refered to as "the LEC"), who maintain a large modem pool to be shared by all subscribed DSPs. Thus, a DATS allows the DSPs to operate a Virtual Private Dial-in Network (VPDN), where calls and virtual resources to the said DSP
remain private and confidential, even though the physical facilities are shared among multiple DSPs.
DATS calls, which can be recognized by the dialed number by the originating switch, can be immediately diverted to the DATS equipment via direct trunking facilities, thus removing long duration data calls from interoffice facilities, tandem and egress switches.
Additionally, LECs can also implement front-end devices that recognize end-user data calls and divert the calls to DATS equipment via direct trunking facilities, thus CA 02206616 1997-0~-30 removing such calls from the originating switch as well, effectively removing PSTN congestion due to long duration data calls.
DATS tariffs can be based on the number of logical modem ports subscribed to (which defines the maximum number of simultaneous end-users who can access that particular DSP via DATS), and the Wide Area Network (~AN) link(s) that provide connectivity between the DSP data equipment and the DATS data equipment (which defines the maximum lo instantaneous aggregate bandwidth available to all end-users connected to that particular DSP via DATS). End-user A~A (Authentication, Authorization, and Accounting) can be performed by the LEC on behalf of the DSP, or alternatively, the LEC can perform only partial authentication and forward on the information to the DSP
via tunneling protocols such as Layer 2 Forwarding (L2F), Point-to-Point Tunneling Protocol (PPTP), or Layer 2 Tunnelling Protocol (L2TP).
The DATS does effectively remove the PSTN
congestion issue, and can provide DSPs a more cost-effective arrangement than managing their own modem pool (the subscribed DSP benefits from the economy of scale provided by the LEC's DATS large modem pool). However, some issues arise with this implementation. First, the LEC
providing the DATS must ensure that it can guarantee to its subscribed DSPs a pre-defined quality of service. That is, the LEC needs to guarantee that a particular DSP will have access to the number of logical ports it has subscribed to (with an agreed blocking ratio). To meet this requirement, the LEC must be able to enforce a given DSP's service quota so that, during periods of high demand, a DSP will not use more resources, or ports, than it has subscribed to, which results in lost revenue to the LEC, and may negatively impact other DSPs' service quality. This is a challenging requirement, since it involves a real-time view of all simultaneoius users connected to each DSP, and the ability to refuse connectivity to a particular DSP (should a CA 02206616 1997-0~-30 connection request exceed that DSP's service quota).
Another issue with DATS relates to the distribution of calls over multiple DSP Network Gateways (NGs). If tunneling protocols are to be used, a DSP may interface with the DATS via more than one Network Gateway, which terminates the tunelling protocol. In such cases, it is important that the DATS system maintain an even call distribution on the Network Gateways, such that each end-user who is connected to the DSP is provided with the same lo quality of service (bandwidth, delay, etc.) as other connected end-users. Additionally, a DSP may install Network Gateways of different processing power, such that it becomes important that the DATS system distribute the calls based on the processing power and bandwidth handling capability of each Network Gateway. ThiS is a challenging requirement, since it involves a real-time view of all simultaneous users connected to each DSP's Network Gateway, and the ability to direct new data calls to specific Network Gateways, taking into account the Network Gateway's proccessing power and bandwidth handling capability.
An important service offering for ISDN BRI end-users is the ability to support Multilink Point-to-Point Protocol (PLP), which binds the two B-channels of an ISDN
BRI connection together, given the end-user 128 kbps of effective throughput. In order for the MLP to function, however, all associated MLP segments (known as a MLP
bundle) must be sent to the same Network Gateway when a tunnelling protocol is used. However, the PSTN may route different segments of a MLP bundle to diverse DATS
facilities, to different pieces of equipment that route calls to Network Gateways independently. While this is an inherent characteristic of a DATS system that improves reliability, it also makes MLP coordination a challenge.
Also, some ISDN terminal adaptors can send data in a 56 kbps format (as oposed to the traditional 64kbps format), as some LECs charge higher rates for 64 kbps ISDN calls.
This can cause problems, however, as DATS equipment CA 02206616 1997-0~-30 receiving the call would interpret the call (based on the ISDN signalling message) as an analog call, and route the call to analog modem digital signal proccessor, which would cause the call to fail. A DATS system needs an implementation that can indicate that an incoming ISDN call is of the 56kbps data format, so that it can treat the call appropriately.
Finally, a DSP who subscribes to a DATS, while it would benefit from removing the need to physically manage a lo modem pool, also loses acces to vital operations information it needs for activities such as customer service, marketing, troubleshooting, forecasting, and engineering. Also, some DSPs may require some real-time service tuning (for example, changing the DSP's number of lS ports available). A DATS must be able to provision DSP
service attributes in real-time, provide access to real-time access to service information for troubleshooting purposes, as well as provide a repository of past system performance, for DATS performance analysis. Since the DATS
may be quite large an implementation (on the order of tens of thousands of ports), it is important for LEC operations efficiency that this information be kept in a central, easily accessed location. Also, it is sometimes necessary for the LEC and/or DSP to alter the administrative state of a DATS network element, that is, to disallow new calls from being routed through the said network elements (for example, if the said device software is to be upgraded), while at the same time allowing existing calls already assigned to the said device to remain unaffected (such 30 calls would be removed when the end-user terminates the call). This poses a challenge for the LEC, as today's DATS
implementations involve the distributed installation of multiple modem termination units (a modem termination unit is also known as a Network Access Server (NAS), which can 35 typically support up to 100 multiple end-user data sessions).
Traditionally, centralized control and monitoring CA 02206616 1997-0~-30 of data equipment is implemented using network management applications that employ standard management protocols such as Simple Network Management Protocol (SNMP). The management applications, however, were not designed for real-time service control applications, where the response time must be sufficiently low so as not to exceed either PSTN voice call timers, or end-user call response expectations.
Summarv Of The Invention lo It is an object of the present invention to provide a new and improved data access transport service.
The invention, therefore, according to one aspect provides a system whereby analog modem and/or ISDN BRI data calls to a DATS are processed in real time in order to enforce service quotas, process requirements based on data call service type, balance calls across DSP terminating devices, suppport MLP and 56kbps features for ISDN, and provide access to real-time network status information. The invention also provides the ability to invoke administrative states on specific network elements involved in a Data Access Transport Service (DATS), wherin the control is applied centrally Another aspect of the invention is a method for centralized real-time control of a distributed DATS system.
The method includes steps for determining the number of active call resources to a DSP and limit the number of simultaneous call resources (to a particular DSP) to a pre-configured value, where call resources may be the number of call sessions, the bandwidth utilized by each call, the aggregate bandwidth used by the call sessions, etc. The method also includes steps to distribute calls to a DSP's multiple Network Gateways so that a pre-determined relative load on each Network Gateway is maintained, and so that all segments of a MLP bundle are routed to a common Network Gateway. The method also allows for the distinguishing between analog modem calls versus ISDN data calls, and between ISDN 64kbps versus 56 kbps data call formats. The CA 02206616 1997-0~-30 method also provides a repository of centrally stored service configuration data, as well as historical call and event logs and operational measurement. Additionally, the method provides a method by which a central directory of information may be maintained against DSPs, and against individual DATS system components, allowing this information to be transmitted to individual DATS system elements (such as the NAS, the Network Gateway, Management Systems, etc.). Finally, the method provides the ability lo to perform DATS system element auditing, to ensure that DATS elements are operating as expected.
In accordance with the invention, a telephone switching system routes an analog modem or ISDN BRI call to a Network Access Server (NAS) of a DATS system. This routing is performed based on the dialed number, which the telephone system recognizes as a DATS number. In addition to routing the call to the NAS, the telephone system also provides the NAS with the dialed number, as well as the calling party's number (via standard telephony signalling techniques such as Primary Rate Interface (PRI) signalling or Common Channel Signalling number 7). Upon completion of the routing of the call at the NAS, the NAS then indicates a connection setup request to an Internet Protocol Data Call Control Server (hereinafter referred to as a "Network Controller" (NC) ), including information such as the dialed number, call type (analog modem or ISDN data), and a unique call identifier. This indication is transmitted via a logical signalling path between the NAS and the NC. The NC matches the dialed number against stored DSP
information, and, based on the information, determines if the call should be completed (based on the number of active calls to the DSP). The NC then signals the NAS with an indication that either authorizes or refuses the call. The decision to accept or refuse the call is based on the available resources in the DATS network, both physical and logical (for example, the number of active calls to the associated DSP, or bandwidth available on affected links, CA 02206616 1997-0~-30 or processing/call handling capacity remaining on individual components) and the validity of the requested resources ~for example, the dialed number). If the call is authorized, the Network Gateway to which the data call will be routed is indicated to the NAS (based on Network Gateway load balancing and MLP handling algorithms), along with additional service-related information (such as an indication that a call originally detected by the NAS as an analog modem call is actually a 56kbps ISDN data call), and lo an active call count for the DSP is incremented. The NAS
then completes the call to the indicated Network Gateway using appropriate end-user A~A, control, and communication protocols. Upon termination of the data call (either by end-user or DSP action), the NAS signals to the NC that the call has been terminated, including information such as the termination cause, send and receive data rates, and tunnel protocol information (if a tunnel protocol was used in completing the call). This information is stored at the NC
for later analysis or troubleshooting purposes.
Additionally, the NC can also terminate a call if required, in which case an indication is sent to the NAS instructing it to release the call.
In one example, an LEC may implement a DATS system in order to relieve Public Switched Telephone System (PSTN) congestion, as well as provide value-added transport services to DSPs. In such a scenario, the LEC would install a number of NASs with connectivity to the PSTN, creating a large modem pool, which is shared by DSPs who subscribe to the DATS. Note that while described as a modem pool, the installation of NASs may also support ISDN
data calls, or other data access protocols such as ADSL.
Each NAS has connectivity to each DSP via logical data network connections such as those provided via X.25, Frame Relay or ATM. Each DSP subscribing to the DATS requests a number of logical modem or ISDN data ports, as well as the bandwidth of the network connection into the DATS system.
Note that the number of ports determines the total number CA 02206616 1997-0~-30 of simultaneous calls (or ISDN B-channels in the case of ISDN data calls) to the DSP via the DATS. In its efforts to ensure that each DSP will have avalable to it the resources subscribed to, the LEC will install a NC, thus allowing the LEC to limit calls to a particular DSP.
Analog modem and ISDN data call limits (or service quotas) can be enforced separately, or can be combined.
Additionally, if the DSP requires multiple Network Gateways, the LEC can also distribute calls across the lo multiple Network Gateways, and can ensure that individual segments of a MLP bundle are routed to a common Network Gateway. The LEC would access the historical logs and operational measurements stored on the NC in order to forecast DATS growth, identify potential points of congestion, troubleshoot network failures, or trace the cause of customer complaints.
Brief Descri~tion Of The Drawinas The invention will be better understood from the following description of a data access transport service (DATS) system, together with reference to the accompanying drawings in which:
Figure 1 is a schematic representation of a prior art DATS system;
Figure 2 is a schematic representation of a prior DATS system including a NC, in accordance with the present invention; and Figures 3a and 3b are flow charts manifesting operation of the DATS system of Figure 2.
Detailed Descri~tion Referring to Figure 1, an end-user's personal computer (PC) outfitted with either a modem or an ISDN
Terminal Adaptor (TA) 1 is connected via the subscriber loop 2 to a central telephone switching office (CO) 3.
The CO 3 is connected directly, or indirectly (via tandem switching systems) to a Network Access Server (NAS) 5 via a CO trunk 4. The NAS 5 contains the Digital Signal Processing circuitry (not shown) required for the support CA 02206616 1997-0~-30 of analog modem calls, as well as the HDLC and signalling processor (also not shown) required for ISDN data call support. The NAS 5 also supports end-user authentication schemes such as PAP, CHAP, and RADIUS; link-layer protocol processing such as Serial Link Interface Protocol (SLIP), Point-to-point protocol (PPP); tunnelling protocol such as Layer 2 Forwarding (L2F), Layer 2 tunnelling protocol (L2TP); and, data networking protocols such as Transport Control Protocol (TCP), User Datagram Protocol (UDP), Internet Protocol (IP); as well as link-layer protocols such as Ethernet, Frame Relay, X.25, or Asynchronous Transfer Mode (ATM). The NAS 5 connects to the DSP's Network Gateway 9 via a data network 7. The NAS 5 connects to the data network 7 via a NAS Data Network Interface 6, using protocols such as Ethernet, Token Ring, Fiber Distributed Data Interface (FDDI), Frame Relay, or ATM.
The Network Gateway connects to the data network via the DSP Data Network Interface 8 , using protocols such as Ethernet, Token Ring, Fiber Distributed Data Interface (FDDI), Frame Relay, or ATM. The data network 7 provides the necessary protocol interworking (not shown) in order to achieve compatibility bewteen interfaces 6 and 8. The Network Gateway 9 provides the tunnelling protocol termination on the DSP side. The Network Gateway 9 is connected to other DSP devices and resources 11 such as information servers, or an internet backbone gateway, which provides connectivity to the public Internet Backbone.
Referring to Figure 2, the same DATS configuration as described by items 1 to 11 in Figure 1 is used, with the addition of a Network Controller (NC) 12, and a NC
Management Terminal 14. The NC 12 is connected to the NAS
5 via the data network 7. The NC 12 is connected to the data network 7 via the Network Controller Data Network Interface 13, using protocols such as Ethernet, Token Ring, Fiber Distributed Data Interface (FDDI), Frame Relay, or ATM. The data network 7 provides the necessary protocol interworking (not shown) in order to achieve compatibility CA 02206616 1997-0~-30 bewteen interfaces 6 and 8, and between interfaces 6 and 13. The NAS 5 and the NC 12 support the signalling protocol required to exchange data call control information. LEC operations personnel may configure NC
service via a NC Management Terminal 15, which is connected to the NC 12 via the NC Management Terminal Interface 14.
The NC Management Terminal 15 can be either an ASCII
terminal capable of sending command-line interface commands to the NC 12, or, alternatively, can also be a workstation lo running SNMP-based management applications. The NC
Management Terminal Interface 14 can be either a direct connection, such as RS-232, or can utilize Local Area Network (LAN) and Wide Area Network (WAN) technologies such as Ethernet, Frame Relay, or Asynchronous Transfer Mode, allowing the NC Management Terminal to be located remotely from the NC.
In order for the DATS call control function to be invoked, a call destined to a subscribed DSP is completed through the central office 3 to the NAS 5. Of necessity, such calls include signalling of the DSP directory number from the CO lO to the NAS 5. Referring to Figure 2, the call is originated by an end-user via a PC 1 outfitted with either an analog modem or an ISDN Basic Rate Interface (BRI) Terminal Adaptor (TA). The number dialed by the end-user 1 is sent via Dual Tone Multi-Frequency (DTMF) or pulse signalling to the CO 3, where the dialed number is recogni~ed as a DATS-associated number and routed appropriately to a NAS 5 via a CO trunk 4, providing the dialed number and calling party number to the NAS 5 via signalling depending on the CO trunk 4 type. The NAS 5 in turn sends a connection setup request to the NC 12 using a message-based signalling protocol understood by both the NAS 5 and the NC 12. This protocol may include information that authenticates the NAS to the NC, and the NC to the NAS
(for example using NAS/NC identifiers and shared secrets, both of which may be encrypted). Provided in the connection setup request message is the dialed number, the calling party number, the call type (analog or ISDN data) a unique NAS identifier, and a unique call identifier. Other call resources such as requested bandwidth may also be included. The NC 12 first checks the validity of the NAS
identifier and the dialed number indicated in the connection setup request message. If the information is determined to be invalid, that is, if either the NAS
identifier or the dialed number do not match the list of NAS identifiers and dialed numbers stored in the NC 12, the NC 12 replies to the NAS 5 with a connection setup response indicating a response code that the NAS 5 interprets as a refusal, which results in an error indication ~i.e. fast busy tone or disconnect for an analog modem call, or appropriate ISDN signalling message for an ISDN data call) to the end user 1. If the information received by the NC
12 in the connection setup request message is valid, the NC
12 checks the number of active call resource(s) currently logged against the dialed number (or dialed number group of which the dialed number is a member). A call resource may be a physical or logical entity required to complete a DATS
call (for example, the number of logical ports, the bandwidth available for each call, the aggregate bandwidth for all calls to a DSP). If the number of active call resource(s) is equal to the call resource limit(s) stored against the dialed number or dialed number group, the NC 12 replies to the NAS 5 with a connection setup response indicating a response code that the NAS 5 interprets as a refusal, which results in an indication to the end user 1 that all circuits are busy. If the number of active calls is less than the call limit associated against the dialed number or dialed number group, the call processing proceeds. If a tunnelling protocol is used by the NAS, the NC 12 then chooses a destination Network Gateway from a list of Network Gateways (associated against the dialed number or dialed number group) stored in the NC 12 If the incoming call is a segment of a MLP bundle, then the appropriate Network Gateway is chosen to support MLP

CA 02206616 1997-0~-30 requirements. If the call is not associated with a MLP
bundle, Network Gateway selection is based on the current number of active calls on each Network Gateway 9, and a Nework Gateway relative loading factor stored against each Network Gateway listed on the NC 12. If a Network Gateway's administrative state (stored at the NC) has been set to "disabled", the NC does not consider the Network Gateway in the load balancing algorithm. In order to prevent mesh tunnel connectivity between NASs 5 and Network Gateways 9 (resulting in excessive tunnel protocol overhead), the Network Gateway selection can also favor a Network Gateway 9 to which the NAS 5 in question already has a tunnel established. This tunnel favoring is also known as "Tunnel Affinity". The NC 12 then responds with a connection request response with a response code that the NAS 5 interprets as authorization to complete the data call, and the NC active call counts against the dialed number (or dialed number group) and Network Gateway (if applicable) are incremented. Also included in the connection request is the Network Gateway identifier to which the call is to be routed, its data network address, and any additional service information the NAS 5 may need to complete the call. Once authorized to continue with the data call setup, the NAS 5 will begin to process the analog modem signal or ISDN data frames (depending on the call type), and will commence end-user authentication protocols.
If no tunnelling protocol is used by the NAS 5, the NAS 5 performs all AAA, and once the end-user 1 is authorized, the end-user 1 is assigned a nework address (if required), after which end-user originated packets can be routed to the intended address, and end-user detined packets can be routed to the end-user 1. If a tunnelling protocol is to be used, the NAS 5 sets up a tunnel (if one does not already exist), and A~A information is forwarded on to the DSP
authentication device according to the tunnelling protocol methods. If a network failure condition exists, such that the NAS is unable to open a tunnel to the Network Gateway CA 022066l6 l997-0~-30 indicated by the NC, the NAS sends an indication to the NC
requesting a new Network Gateway allocation, which will result in a response from the INC with a new Network Gateway , and the NC marks the failed Network Gateway administrative status as "disabled", which will prevent further calls from being routed to the failed Network Gateway. Once the end-user 1 is authorized, the end-user 1 is assigned a nework address (if required), after which end-user originated packets can be routed to the intended address, and end-user detined packets can be routed to the end-user. Once the end-user 1 has been authenticated, the NAS 5 sends a connection confirmation indication, which includes information relating to the data call, such as initial send/receive data rate, Network Gateway identifier, and tunnel identifier (if required). If at any time end-user authorization fails, the end user 1 is disconnected according to the associated authorization protocol, and the NAS 5 sends a connection release indication to the NC 12 with the appropriate termination code and associated connection identifier, and the NC active call counts against the dialed number (or dialed number group) and Network Gateway (if applicable) are decremented. Data call release occurs if the end-user 1 ends a session, if the DSP
ends a session, or if the NC 12 forces a session to be released (as a result of a LEC personnel command to the NC
via the NC Management Terminal). If the data call is to be released as a result of end-user 1 or DSP action, the NAS 5 sends the NC 12 a connection release indication with an appropriate and mutually understood cause code and connection identifier, to which the NC 12 responds with an acknowledgement message, and the NC active call counts against the dialed number (or dialed number group) and Network Gateway (if applicable) are decremented. If the data call is released as a result of an LEC personnel command to the NC 12, the NC 12 sends the NAS 5 a connection release indication with an appropriate and mutually understood cause code and connection identifier, -CA 02206616 1997-0~-30 to which the NAS 5 responds with an acknowledgement message, and the NC active call counts against the dialed number (or dialed number group) and Network Gateway (if applicable) are decremented. If, at any time, a network failure occurs such that multiple end-user sessions are lost and/or tunnel connectivity is lost, the NAS 5 will send multiple connection release indications with an appropriate and mutually understood cause code and connection identifier, to which the NAS 5 responds with o corresponding acknowledgement messages, and the NC active call counts against the associated dialed number(s) (or dialed number group(s) ) and Network Gateway(s) (if applicable) are decremented.
If at any time a NAS-generated connection setup request is associated against a NAS 5, dialed number, dialed number group, or Network Gateway that has been marked at the NC as being administratively disabled, the NC
12 replies to the NAS 5,with a connection setup response indicating a response code that the NAS 5 interprets as a refusal, which results in an error indication (i.e. fast busy tone or disconnect) to the end user 1.
At regular intervals, the NC 12 may send a status indication to one or more NAS 5, to which the NAS 5 responds with a status confirm message (using the aforementioned signalling protocol). The status confirm message will include a list of all currently active calls, with their identifiers. The NC 12 uses this information to determine if the information stored in the NC 12 is accurate. If the information is not accurate (i.e. some 30 unexpected new calls may be present or some expected calls may be absent), the NC 12 updates its information, and may send another status indication to the NAS requesting more detailed information.
All connection setup requests, connection setup 35 responses, connection release requests, connection release acknowledgements, status indications, status confirmations, many error conditions and statistics are logged or counted CA 022066l6 l997-0~-30 for post analysis purposes. In addition, all current (active) call information is stored at the NC for real-time querying and troubleshooting.
The functions as discussed in the 6 preceeding paragraphs are illustrated in the flow chart in Figure 3a and Figure 3b.
It will become aparent to the reader that the basic data call control and monitoring features described herein, and varations of the same, may well be enhanced.
lo For example, such enhancements include time-of-day dependent DSP service quotas, application to newer access technologies such as ADSL, implementation of redundant NCs, distributing multiple NCs to increase scaleability, supporting mechanised DSP management interfaces for real-time querying of DATS-related statistics by DSP personnel, and incorporation of other signalling protocols such as common channel signalling system number 7 (CCS7) and IN
interworking.
Those skilled in the art will recognize that various modifications and changes could be made to the invention without departing from the spirit and scope thereof. It should therefore be understood that the claims are not to be considered as being limited to the precise embodiments set forth above, in the absence of specific limitations directed to each embodiment.

Claims (10)

WE CLAIM:

1. A method for operating a Data Access Transport Service system in conjunction with an Internet Protocol Data Call Control Server (also known as a "Network Controller") for providing centralized real-time call control functionality wherein the Network Controller can exchange information with a Network Access Server (NAS) in real-time via a signalling path and protocol. Information exchanged allows the Network Controller and the NAS to setup DATS calls, tear down DATS calls, and exchange additional configuration information.

2. A method for enforcing service quotas in a DATS
system, wherin a Network Controller prevents any subscribed DSP from exceeding its agreed limit of simultaneous data calls, which is defined as a single analog modem connection, or one ISDN B-channel connection.

3. A method for distributing data calls across multiple Network Gateways (if a tunnelling protocol is to be used), using pre-defined relative loads assigned to each Network Gateway, wherein a Network Controller maintains a count of active calls against each Network Gateway, and on each connection setup request from a NAS, returns a response with an indication of the Network Gateway the call is to be routed to, with enough information such that the NAS can complete the call.

4. A method for re-allocating DATS calls to an alternate Network Gateway (using the method outlined in 3), if the NAS signals the NC that it has failed to open a tunnel to the original Network Gateway allocated to a particular DATS call.

5. A method for reducing the tunnelling protocol overhead in a DATS system, wherein a Network Controller will continue to indicate a Network Gateway for calls routed through a particular NAS, to a particular DSP, such that a tunnel to the said Network Gateway previously in existence, until which time the said Network Gateway's aggregate load exceeds a pre-defined level.

6. A method for routing individual segments of a MLP
bundle to a common Network Gateway, wherein a Network Controller will receive indication from the NAS that an incoming call belongs to an existing MLP bundle, thus allowing the Network Controller to indicate to the NAS to connect the call to the same Network Gateway that is currently supporting the other MLP segment(s).

7. A method for distinguishing between 64kbps versus 56kbps ISDN data call formats in a DATS system, wherein a Network Controller, after being sent a connection setup request by a NAS, has been configured to indicate to the NAS (based on the incoming call's dialed number) that the incoming call is to be treated as an ISDN 56kbps formatted call.

8. A method for providing centralized access to current and historical data relating to the operation of a DATS system, whereby Network Controller data is accessed via a Network Controller Management Terminal, and that such data is stored as a result of the signalling interaction between the said Network Controller and all Network Access Servers it controls.

9. A method for assigning and enforcing administrative states on individual DATS system elements (namely, the NAS, Network Gateway, as well as dialed number and dialed number group configurations stored on the Network Controller), wherein a Network Controller configuration is updated, via the use of a Network Controller Management Terminal, to reflect changes to administrative states stored against each NAS, DN, DN
group, or Network Gateway that is controlled or maintained in the DATS system by the Network Controller, such that (a) If the administrative state of a Network Gateway is set to "disabled" the Network Controller will not route any subsequent calls to the said Network Gateway, nor will the Network Controller consider the said Network Gateway's current load in the load balancing algorithms, while existing calls previously routed to the said Network Gateway remain unaffected.
(b) If the administrative state of a NAS, a particualr dialed number or dialed number group is set to "disabled" the Network Controller refuse connection setup requests sent by the said NAS, and will also refuse connection setup requests sent by any NAS to the said dialed number, or dialed number group, while existing calls previously routed through the said NAS, or to the said dialed number or dialed number group remain unaffected.

10. A method for maintaining a centralized view of the network that is deemed to be accurate within a