METHOD FOR MANAGING CHANNELS CONTAINED IN A TRANSMISSION ROUTE
Technical Field
The present invention relates to a method according to the preamble of Claim 1 for distributing the capacity of a transmission route containing several data transmission channels between subscribers in a system, in which each transmission capacity subscriber has been guaranteed a previously agreed number of guaranteed data transmission channels. The invention also relates to a method for providing a subscriber connection with channels to be used in data transmission.
The invention also relates to a computer program product according to Claim 8 for distributing the capacity of a transmission route containing several data transmission channels between subscribers, in a system in which each transmission capacity subscriber has been guaranteed a previously agreed number of guaranteed data transmission channels.
The technical area of application of the method that is the object of the invention is the distribution of data transmission capacity in a transmission route used to transmit data in a digital form, which route comprises channels able to be connected for parallel data transmission. Such a transmission route can be based on e.g. ISDN, GSM, or UMTS technology, or also on SVC-based ATM technology (Switched Virtual Circuits,
Asynchronous Transfer Mode). One specific application of the invention is the distribution between subscribers of connection channels used in network access servers.
Background Art
According to the state of the art, the channels of transmission routes are distributed according to a previously agreed division so that, for example, subscriber A is guaranteed X channels, subscriber B is guaranteed Y channels, and subscriber C is guaranteed Z channels. Though such an arrangement is clear, it nevertheless leads to an inefficient use of transmission capacity, as, for example, the channels reserved for subscriber A are completely empty when subscriber A is not using them her or himself.
At the same time, subscribers B and C may be using all their channels and the number of data transmission channels available may be the factor limiting the speed of data transmission. Furthermore, the said arrangement may have additional unused channels, if all the channels permitted by the physical transmission route have not been 'sold', i.e. reserved for anyone.
Systems are also known, in which subscribers can open some channels that are free, besides the guaranteed channels that they have reserved. Such systems have, however, the very serious drawback that opening so-called surplus channels (i.e. channels that can be opened in addition to the guaranteed channels) for a subscriber may result in the transmission route becoming full so that some subscriber cannot make a connection at all through the transmission route. In less dangerous situations, the subscriber may be able to make a connection, but receives fewer channels for her or his use than were guaranteed in the agreement. To allow transmission routes to be used more efficiently and to give all subscribers using the connection services a better service, some kind of new channel -routing method is required, which does not have the drawbacks referred to above.
Disclosure of Invention
The invention is intended to create a method, which can be used to distribute data transmission routes' channels among subscribers in an advanced manner, allowing the capacity of the transmission routes to be used efficiently, but nevertheless always providing each subscriber with the promised transmission capacity. The invention is also intended to create a computer program to implement such a method.
The invention is based on guaranteed channels, up to a previously agreed maximum number, being opened for each subscriber on the basis of channel-opening requests. In this case, a guaranteed channel refers to a connection channel that can be closed only from a connection-closing request sent by a user of the connection. Here, the user of the connection can be, for instance, the original subscriber of the connection or the party responding to the connection. If the subscriber is already using the previously agreed maximum number of guaranteed channels, one or more additional channels can be opened on the basis of a channel-opening request, according to programmable
conditions. Here, an additional channel refers to a connection channel that can be closed in a transmission route loading situation, by the operator providing the transmission route, without a user of the connection her or himself closing the connection.
More specifically, the method according to the invention for distributing the capacity of a transmission route containing several data transmission channels is characterized by what is stated in the characterizing portion of Claim 1.
The method according to the invention for providing a subscriber connection with channels to be used in data transmission is, in turn, characterized by what is stated in the characterizing portion of Claim 7.
The computer program product according to the invention is, in turn, characterized by what is stated in the characterizing portion of Claim 8.
Considerable advantages are gained with the aid of the invention. This is because the invention can be applied to use the capacity of a transmission routed more efficiently, thus providing a better service for the users of the connection service. It is possible to use transmission capacity more efficiently, because our invention allows channels guaranteed to one subscriber to be opened for use by another subscriber, in situations in which the first subscriber does not need all the guaranteed channels her or himself. In turn, a better level of service is achieved by it being always possible to give each subscriber their guaranteed transmission capacity, and, in addition, usually some extra capacity in the form of additional channels. Thus, if traffic on the transmission route is light, one subscriber may be able to use a very large transmission capacity, with no detriment to other subscribers.
The invention has also many preferred embodiments, by means of which considerable additional advantages are obtained.
For example, the invention has embodiments that permit intelligent pre-authentication to be carried out before the actual connection is formed between the customer device and the modem pool or another corresponding connection service.
In an embodiment of the invention exploiting an ISDN network, the invention can be applied to provide network-access customers with cheap and also effective connections.
Further, the invention can be advantageously applied to implement, on top of a switched ISDN network, a data transmission network corresponding to that which can be implemented by a quite different arrangement in fixed data networks like FrameRelay and ATM networks. In such networks, though customers are guaranteed a specific data transmission capacity under all conditions, they can also use more rapid traffic, if the network has free capacity.
A suitable application of the invention also permits the implementation of a highly- developed centralized network-access solution, in which connections, for example, from different long-distance call areas, are gathered into an easily managed totality.
From the point of view of an operator providing connections, the invention also permits, for example, the maximization of the number of users of network-access equipment while guaranteeing all users a possibility to form connections using at least the guaranteed number of channels.
Brief Description of Drawings
In the following, the invention is examined with the aid of examples and with reference to the accompanying drawings.
Figure 1 shows an example of one system using the method according to the invention.
Figure 2 shows an arrangement according to one embodiment of the invention utilizing Radius queries.
Figure 3 shows greater detail of the processing of Radius requests, in the embodiment according to Figure 2.
Figure 4 shows some operations relating to the booting of the software according to the invention.
Figure 5 shows the authentication of connections according to one embodiment of the invention.
The following examples disclose the application of the invention, in connection with connections implemented using ISDN technology. However, from the following
disclosure, it will be obvious to one versed in the art how the method according to the invention can also be applied in connection with other transmission routes, based, for example, on ATM, GSM, or UMTS technology.
Definitions
The following terminology is used in this document:
DBHJ: A method or system able to distribute transmission channels dynamically.
Modem pool: Equipment between a public telephone network (PTW) and a data network, which can connect users coming through a switched telephone network, to become part of a fixed data network.
B channel: In connections implemented with ISDN technology, the connections are based on B channels. Each B channel can transmit unpacked digital data at a rate of 64kb/s. Several such B channels can be opened simultaneously between a customer device and a modem pool, when an n*64kb/s connection (n = 1 , 2, 3, 4...) is obtained.
BRJ: An ISDN connection, with two B channels and one D channel available. The name of the connection comes from the words Basic Rate Interface.
El: An ISDN connection, with 30 B channels available for connections and one D channel for signalling. The connection is also called a PRI (Primary Rate Interface).
Radius: The RADIUS (Remote Authentication Dial-In User Service) standard was originally a service intended for authenticating users and equipment using switched connections. It can also be applied in other authentication tasks.
Authentication: User identification in a modem pool.
Authorization: The appropriate addresses and other variables are issued to a user.
Accounting: Records (or a log) of the events in a modem pool, including user authentication and authorization.
AAA: Refers to software or equipment performing Authentication, Authorization, and
Accounting.
SNMP: The Simple Network Management Protocol standard for the management of equipment connected to a data network. The protocol can be used to either retrieve or alter status data from the equipment being managed.
Detailed Description
Figure 1 shows a diagram of an example of a system, with DBHJ installed. The system of Figure 1 shows a network access server 1 and a DBHJ server 2 connected to it, by means of which properties according to the invention are produced for the modem pool and its connection. The figure also shows a company network 3, which may be, for example, an ATM/FR network. Company 1 and Company 2 are connected to a company network through their hubs. Hub 4 of Company 1 is connected, for example, using an ATM connection and hub 5 of Company 2 using an FR connection. The figure also shows a branch office 6 of Company 1 , which is connected to modem pool 1 by telephone network 7, and a branch office 8 of Company 1 , which is connected to modem pool 1 by telephone network 9. The figure also shows a branch office 10 of Company 2, which is connected to modem pool 1 by telephone network 1 1.
When the system is in operation, the branch offices of each company can contact their own fixed company networks through the ISDN network. For example, branch office 1 1 of Company 2 is guaranteed a 128kb/s data transmission connection, but if necessary can use a connection of up to 512kb/s, provided free capacity is available in modem pool 1 on the lines in question.
For example, a telecommunications area, from which there are two El interfaces to network access server 1, can guarantee connection formation to fifty-nine (59) customers from the telecommunications area in question, if all customers are guaranteed one B channel. One time interval is reserved for signalling, because, if all 60 time intervals are in use, the local ISDN exchange will send a busy signal to a customer device, and modem pool 1 will not see the call-formation attempt at all.
Generally, the method (DBHJ) according to the example can be used by means of separate software, operating in the same sever as the network access server's actual
AAA software. The method can be used particularly with all AAA software supporting the Radius protocol. Then DBHJ acts as a so called Proxy, intermediary, between a
modem pool and the AAA software. All Radius queries and responses sent by the modem pool to the AAA software travel through it. Figure 2 shows such an arrangement.
Figure 3 shows in turn the processing of Radius queries in greater detail. Though all Radius queries and responses between the modem pool and AAA software travel through the DBHJ software, which, in the embodiment in the example, reacts to only three different types of messages. One of these messages is a so-called pre- authentication request, the other two being accounting messages. All other messages are forwarded as such by the DBHJ software.
For its part, the modem pool should meet the following requirements, to be able to operate with the DBHJ according to the example:
- The modem pool should use the Radius protocol for AAA functions.
- The modem pool should send a so-called pre-authentication request to the AAA software, i.e. a calling-number check request.
- The modem pool should support some method allowing an individual B channel to be dropped. A B channel can be dropped, for example, by an SNMP command or a command to be given through a telnet connection.
In traditional connection formation, the connection formation process starts with the customer terminal device detecting that it must form a connection to the modem pool. The customer terminal device sends a connection formation request, a so-called SETUP message, through the ISDN network. At this stage, all that is known about the connection requester is the calling number (the so-called A subscriber number) and information on which El interface of the modem pool it is wished to form the connection through. The modem pool can send the calling number to the AAA software, which can identify the number and allow the call to proceed. Alternatively, the AAA software can reject the call and send a DISCONNECT message to the customer terminal device.
If the modem pool has free B channels, it approves the connection request by responding CONNECT, according to the ISDN protocol. At this stage, the ISDN
network begins to charge metering impulses to the calling party (customer terminal device). After this, the customer terminal device sends it own username and password to the modem pool, which authenticates them from the AAA software. If the codes are correct, a data connection is formed and traffic can commence. If the codes are wrong, the connection is broken.
If DBHJ functions are added to a traditional operating model according to the example, the actual operation of the DBHJ occurs in the so-called pre-authentication stage. The customer terminal device then begins to form the connection by sending the modem pool a SETUP message. The modem pool sends the calling number to the AAA software.
The DBHJ then receives this pre-authentication message and checks:
- Whether it can respond to the connection request.
- Whether some older connection to the modem pool should be broken, to make room for this new connection.
If a response to the connection request is not possible, a DISCONNECT message is sent to the customer terminal device, according to the ISDN protocol, in which case connection formation breaks and the customer is not charged for the call. Otherwise, a CONNECT message is sent in accordance with the ISDN protocol and user authentication proceeds as usual. If necessary, the DBHJ can drop a channel (one B channel) of a user using a broader band from the modem pool than their guaranteed capacity.
Other Authentication and Authorization messages are delivered as such to the AAA software to be used. The DBHJ monitors the Accounting messages from the Radius messages and detects when connections form (START) and terminate (STOP). On this basis, it maintains data on each user's channels and on the reservation status of each El interface group.
Channel dropping is illustrated by the accompanying example, in which, for clarity, only ten (10) channels are used. Normally, however, there are thirty (30) channels in an
El interface. In other systems, the number of channels can of course vary, even greatly, from these examples.
Initially:
- User 1 has two guaranteed channels and one additional channel.
- User 2 has two guaranteed channels and one additional channel.
- User 3 has one guaranteed channel and two additional channels.
Thus, the reservation status of the channels is according to the following table:
In the table, each square represents one channel, and within the square the user of the channel is marked with a number and the type of use with a letter, so that 'G' represents a guaranteed channel and 'A' an additional channel. Thus, 'IG' in the first square means that the channel is reserved as a guaranteed channel of user 1.
If, in the above situation, user 4 wishes to form a connection, a check must be made as to whether a connection can be permitted for user 4. The situation is then as follows:
If the connection desired by user 4 is permitted, an existing connection must be dropped. The system then drops one channel from the user using the most additional channels. If more than one user is using the same number of additional channels, for example, the oldest additional channel, i.e. the one that has been in use longest, is dropped. In the case in the example, user 3 has the most additional channels, so one additional channel is dropped from her or his use. This results in the following situation:
Now the system can wait for a new connection call.
Thus, suitable software is required to implement the above operations. Figure 4 shows the booting of the software. When the software boots, it retrieves the data of each El interface group from the database. The groups are distinguished by the area code, which, in the example, is '09'.
Each group contains a certain number of El interfaces and, on their basis, a specific number of B channels, which can be used to form connections. For example, three (3) El interfaces can be used to make eighty-nine (89) connections. The last free channel must always be retained for signalling. If all the channels were in use, the necessary SETUP messages from new connection requests could not be seen.
When the group data is entered in the system, a status table is created for each connection group, showing:
After this, the modem pool operations themselves can be activated.
Figure 5 shows the connection authentication in greater detail.
When the customer terminal device (generally an ISDN router) detects that it should open either the first data connection or additional channels to the modem pool, it sends an ISDN message over the local telephone network to the modem pool. This message gives the following information:
- The number being called.
- What number is calling.
Now the modem pool sends the AAA server a so-called pre-authentication request. In the solution of the example, this request travels through the DBHJ software, which detects the pre-authentication request in it and can activate its own process from it. In
this case, the pre-authentication request contains, for example, the following information:
- The number called
- The calling number
- The receiving interface in the modem pool (El interface)
- The B channel used
- The time
- and other manufacturer-specific information.
Once it has received the pre-authentication request, the DBHJ checks the status data of the various users in its memory and tries to find the same calling number, by means of which the user can be identified. These data are created in the memory every time a user contacts the modem pool for the first time. If the user's data (calling telephone number) are found, the user is thus identified and the status of the El group can now be checked.
Further according to Figure 5, if the relevant telephone number is not found in the user status data, the database of the AAA software, containing data for all users, is searched.
The search is for a calling-party number corresponding to that in the new call. If such a number is found, the essential data of the relevant user are retrieved to a new user status data variable in the DBHJ software. The status data can include, for example, the following:
- The username: e.g. officel@companyl.fi
- All the calling-party phone numbers: e.g. 03-123456 and 03-4567890
- The B channels guaranteed for this user: e.g. 3
- The maximum permitted number of B channels for this user: e.g. 4
- The channels presently in use: updated according to the user's connection status.
The status data is next checked to see if the user is already using their maximum number of allocated B channels. If so, the connection request is not accepted, the pre-
authentication request response FAIL is sent to the modem pool, and the event is recorded in the DBHJ's log file. The modem pool responds to the ISDN SETUP message with the reply DISCONNECT and connection formation breaks off with no metering impulses.
If, on the other hand, the user is still not using the permitted maximum number of channels, a check whether the El group is full is made. The pre-authentication data sent by the modem pool is then used to determine the El interface group to which the call in question has come. Next, the group's status table is checked to see if all possible channels are already in use. For example, if two El interfaces have been defined for the group, the maximal number of connections is fifty-nine (59). If the relevant group is not yet full, the connection request can be accepted, no matter whether it concerns a guaranteed or an additional channel. The DBHJ responds PASS to the modem pool's pre-authentication request, the modem pool correspondingly replies CONNECT to the ISDN SETUP message sent by the customer terminal device, and actual authentication starts.
Still referring to Figure 5, if the called group is already full, a check is made of whether the customer device sending the connection request is entitled to a guaranteed channel. As an example, the situation when the called El interface group is full will be examined. Now it must be decided whether space must be made in the interface group for the connection request. In this case, the relevant user's status data is examined to see if the user is already using at least the guaranteed number of channels. If so, the request is rejected, the modem pool being sent the pre-authentication request response FAIL. The event is entered in the DBHJ log file. The modem pool replies DISCONNECT to the ISDN SETUP message and connection formation breaks off with no metering impulses.
If, on the other hand, the user is still entitled to use guaranteed B channels, one B channel connection of another user must be dropped from the relevant El interface group. Selection and dropping of the excess channel can take place by, for example, dropping the oldest additional channel, i.e. the one that has been used for the longest time. Dropping can also be carried out by checking the number of additional connections of all users from the El interface group status table and dropping an
additional connection from the user with the most additional connections. If more than one user is using the same number of additional channels, the oldest additional connection is dropped.
Additional connections can also be dropped by, for example, depending on the equipment, sending the modem pool either:
- an SNMP command ordering it to drop the oldest B channel connection from a specified El interface,
- or, if an SNMP command is impossible, making a terminal connection to the modem pool and using a command line to order the relevant B channel to be broken.
The modem pool now has space to allow the connection to be authenticated to open a new B channel connection between the modem pool and the customer device. The DBHJ then responds PASS to the modem pool' authentication request, the modem pool correspondingly responds CONNECT to the ISDN SETUP message sent by the customer terminal device, and actual authentication can commence.
The transmission of authentication requests has already been dealt with above. The DBHJ forwards all Radius authorization requests from the modem pool directly to the actual AAA software.
In the case of accounting data, a possible procedure is for the modem pool to send Account data according to the Radius protocol to the AAA software, whenever something relating to customer connections takes place, for example, authentication succeeds. The DBHJ monitors START and STOP messages from the Account data. These are:
- Acct-Status-Type = Start
- Acct-Status-Type = Stop
In the case of an Account START message, the modem pool sends the AAA software an Account message through the DBHJ. The message shows that the modem pool has
formed a new connection. The following is an example of a Radius Account-Start message:
Wed May 8 10 : 51 : 12 1996
Acct -Session- Id = "2400020E" User -Name = "locationl@companyl.fi"
NAS- IP-Address = 172.16.1.21
NAS-Port = 2:12
NAS-Port-Type = ISDN
Acct-Status-Type = Start Acct-Authentic = RADIUS
Called-Station-Id = "101022"
Calling-Station-Id = "0311223344"
Service-Type = Framed-User
Framed-Protocol = PPP Framed-Address = 172.16.93.1
Acct-delay-Time = 0
Timestamp = 838763356 The above Start message can be used to update:
- the user's status data - a new B channel has been brought into use
- the El -interface group's status data - connection, channel, user, calling number, time, and whether the said B channel is in use as a guaranteed or additional channel. The user's status data is checked for the guaranteed/additional channel data.
In the case of an Account STOP message, the modem pool also sends the AAA software an Account message through the DBHJ. This message shows that the modem pool or customer device has terminated the connection between the modem pool and the customer device. A Radius Account-Stop message can be like the following:
Wed May 8 12 : 50 : 49 1996
Acct-Session-Id = "2400020E"
User-Name = "locationl@companyl.fi"
NAS- IP-Address = 172.16.1.21
NAS -Port -Type = 2:12
Acct-Status-Type = Stop Acct-Session-Time = 7177
Acct-Session-Time = RADIUS
Acct-Input-Octets = 14994
Acct-Output-Octets = 90862
Called-Station-Id = "101022" Called-Station-Id = "0311223344"
Service-Type = Framed-User
Framed-Protocol = PPP
Framed-Address = 172.16.93.1
Acct-Delay-Time = 0 Timestamp = 838763378
The above Stop message can be used to update:
- the user's status data - the B channel is no longer is use
- the El -interface group's status data - connection, channel, user, calling number, time, and whether the B channel in question was taken out of use as a guaranteed or an additional channel.
When the user no longer uses the last B channel, the relevant user's status data are also deleted from the DBHJ software's internal variables. This is to ensure that all changes to the user database can be rapidly applied, without the software having to reboot.
Within the scope of the invention, solutions differing from the embodiments disclosed above can also be contemplated. For example, the operations of a dynamic modem pool can also be implemented without the 'radius-proxy' function. The modem pool must then be able to send the log events to the so-called syslog file. External software could monitor the syslog-file events in real time and decide from them if there is a need to
drop some B channel, to allow some other user to use a guaranteed B channel of the modem pool. However, this embodiment has the drawback of reacting to modem pool events after they have taken place. Thus, users incur unnecessary telephone expenses, if the modem pool drops a connection that has only just been formed. The implementation must also be fully tailored to the modem pool used, as the data sent to the syslog files are device-manufacturer-specific, unlike in the implementation based on the Radius protocol.
Intelligent AAA software can also be used to implement the operations disclosed above. In that case, the software must be able to gather the individual El interfaces into logical groups, for which a maximum number of channels is defined. The software should also be able, when necessary, to command the equipment of each modem pool manufacturer to drop additional channels from a specified El interface group, in connection with pre- authentication. Often, the AAA software supplied with each modem pool is tailored specifically for the equipment of the relevant modem pool manufacturer. Separately implemented AAA software would lose all the advantageous additional features implemented by the equipment manufacturer in its own software.
The operations disclosed in the above examples could also be implemented in an entirely SNMP-based system, if the modem pool equipment supports this management system. The modem pool would then send all event data to the system, which would interpret each user's number of connections and the operating status of the El interface groups from the event data. Correspondingly, the system would give SNMP commands to specific channels to drop connections. The system to be implemented would have to be fully tailored for a specific modem pool, as SNMP status data are modem pool specific.
From what is disclosed above, it is obvious to one versed in the art that our invention can be applied widely to manage data transmission connections relating to modem pools. It is also obvious to one versed in the art that our invention is not, however, in any way limited to modem pool operation, but that our invention has also numerous applications in other applications requiring large or largish data transmission capacity, in which data transmission channels are distributed between several users or processes.