Kirsti A Løvnes, Frank Bruarøy, Tom Handegård and Bengt G Jensen
This paper describes and discusses the modelling of connection control functionality in a B-ISDN (Broadband ISDN) trial network under development at Norwegian Telecom Research. The main objective of our work is to experiment with IN control of B-ISDN. The virtual switch concept adopted from ETSI/NA6 enables a decoupling of service logic and network technology.
So far the research and standardisation on IN and B-ISDN has progressed more or less independently. The basic IN concept, separation of service control and switch control, has been motivated by a need for rapid and independent evolution of services and technology and a need for advanced addressing facilities. At this point in time, IN architectures proposed by standardisation bodies (CCITT/ETSI) are not taking into account B-ISDN service requirements. On the other hand, effort has been put into the standardisation of a control architecture and signalling for B-ISDN without taking advantage of the results obtained from the work on IN.
B-ISDN is likely to offer a wide range of multimedia/multiconnection services (point-to-point and point-to-multipoint) needing complex call handling functions (8, 9). There is no longer a simple one to one relationship between a call and a connection. A call may be associated with a number of connections, the number and quality of the "active connections" varying as the call progresses. Furthermore, advanced call negotiation capabilities will be needed for interworking between end- users with different terminal capabilities. An evaluation of the B-ISDN service requirements leads to a control architecture which enables calls to be established and controlled independently of associated connections. This implies separation of service handling and connection handling functionality.
A strong relationship exists between the basic IN concept and the concept of service and connection control separation in the B-ISDN control architecture. However, the IN architectures proposed by standardisation bodies will need some modifications to incorporate B-ISDN requirements. Taking both the basic IN concept and B-ISDN service requirements into account, we want to visualise the separation between service processing functionality and functionality associated with manipulation of the communication resources in the underlying B-ISDN network. Our implementation of the interface between service logic and network technology is based on the Connection Control Socket described in the IN Connection Control Model proposed by ETSI/NA6 (1). This paper describes and discusses a possible implementation of the model in a B-ISDN network.
Norwegian Telecom Research participates in a wide range of B-ISDN activities. As part of these activities, a B-ISDN trial network is being developed. The network will serve as a testbed for IN supported B-ISDN connection control functionality and ATM (asynchronous transfer mode) traffic and performance.
B-ISDN is the new broadband network currently under development and standardisation by CCITT (6, 7). It offers the prospect of extending the range of services offered by ISDN considerably. B-ISDN is planned to support services with both constant and variable bit rate for transmission of data, voice, sound, still and moving pictures and multi-media applications which may combine any of these components.
The transfer mode chosen for B-ISDN is called asynchronous transfer mode (ATM). The term transfer comprises both transmission and switching aspects; thus ATM is a technique for transmitting and switching information in a network.
All information to be transferred in ATM is contained in cells of a fixed size. The cells have a 48 octet information field and a 5 octet header. The information field is available for the user. The header carries information which is used by the ATM network itself. Its main component is a label for identification of cells.
ATM is a connection-oriented technique. Individual connections are recognised from the label field inside the ATM cell header. The term asynchronous refers to the fact that cells belonging to a connection are sent according to the actual need, and thus may appear in an irregular way. This is illustrated in Figure 2.
The connections offered in an ATM network are called virtual channel connections. A virtual channel connection is a concatenation of one or more virtual channel links. A virtual channel link typically spans a single physical link betwen two network nodes (switches, terminals, etc). Each virtual channel link is assigned an identifier. This identifier is called the virtual channel identifier (VCI) and is part of the cell header. The VCIs for a connection normally remain unchanged for the duration of the connection, although there may be exceptions, as explained later.
The virtual channels are unidirectional. All cells associated with an individual virtual channel connection are transported along the same route through the network. Cell sequence is preserved, but cells may be lost. A bidirectional connection is realised by means of two unidirectional virtual channel connections.
The ATM switch is capable of interconnecting incoming virtual channel links with outgoing virtual channel links. This implies two main tasks: Translation of VCI and cell transport from ingoing to outgoing physical links.
Point-to-point, point-to-multipoint as well as multipoint-to-point configurations are possible. Figure 3 illustrates point-to-point and point- to-multipoint configurations. As shown, point-to-multipoint configurations imply copying of cells from an incoming physical link (link2(vci11)) to two or more outgoing physical links (link3(vci3) and link4(vci3)). On the contrary, multipoint-to-point configurations imply multiplexing of cells from two or more incoming virtual channel links to one outgoing virtual channel link.
The switch is capable of differentiating between reserved and through- connected connections. For a connection which is only reserved, cell transport on the given connection is inhibited although resources to carry out the cell transport for the connection have been reserved.
Figure 4 shows an early version of the trial network consisting of an ATM switch, a customer premises network (CPN), terminals, transmission system and control units (service control units and connection control units). The network elements are interconnected by ATM based optical transmission systems with bit rates of 155 Mbit/s. Later versions of the trial network will be expanded with more ATM network elements (switches, CPNs, terminals, etc.). Furthermore, interworking units enabling communication with MANs, LANs and ISDN will be introduced.
As seen from Figure 4, the optical links are used for user data only (i.e. speech, audio, video). Control information is sent on a separate signalling network implemented by standard Ethernet. The use of Ethernet as a dedicated signalling network enables a decoupling of signalling and transport problems.
The connection control activity is a cooperation between IN and broadband research activities. The main objectives of our work is to verify system concepts and architecture, implement a connection control system for the trial network and explore the interaction between services (existing and future) and the ATM network. Through our modelling and implementation work we also gain experience with object oriented techniques.
As shown in Figures 4 and 5, the control architecture is composed of two control domains: service control (SC) and connection control (CC). In Figure 5 one CC node controls its separate ATM switch. Arrows are indicating the interfaces between a CC node and the SC domain, between two CC nodes, between a CC node and a terminal, between the SC domain and a terminal and between a CC node and an associated ATM switch.
In summary, the service control domain contains the service logic necessary to process service requests from end-users, while the connection control domain contains the functionality needed to establish, modify and release the requested connections in an ATM network. A more detailed description of the functionality of SC and CC follows in section 3.
As our implementation of the SC-CC interface is based on the Connection Control Socket Model (CCSM) developed by ETSI/NA6, a brief description of its basic objects and service primitives will be given before going into a more detailed discussion of our control system.
The Connection Control Socket Model is one of the components of the Connection Control Model (CCM) in the ETSI IN architecture (1). The other two components, Basic Call Model and Connection Segment Relationship Model, are not included in our prototype.
The Connection Control Socket Model was chosen for our implementation as it seems to be in line with some of the main IN objectives:
In this model the service instance views the network as a virtual switch object consisting of two types of attributes: legs and connection points. Each virtual switch may own several legs and connection points.
A leg is an abstract representation of a communication path extending from a connection point to an addressable network entity (e.g. a terminal). A leg may be unidirectional or bidirectional.
A connection point (CP) represents an interconnection allowing information to flow between legs. The legs associated with a connection point may be joined (connected to the CP) or split (disconnected from the CP). In our implementation of the socket, a leg is always associated with a connection point.
Figure 6 illustrates a socket containing a connection point and three associated legs. Two of the legs are joined (i.e. information flows between them), while the third leg is split from the connection point (i.e. no information is allowed to flow between this leg and the other two legs).
Below follows a short description of the service primitives across the SC-CC interface:
open_socket: This message is sent from SC to CC to indicate the start of a session.
create_cp: This message is sent from SC to CC to request creation of a connection point. In our implementation a connection point must always be created before legs are created.
create_leg: This message is sent from SC to CC to request creation of a leg. Create_leg implies reservation of necessary communication resources in the ATM network.
join: This message is sent from SC to CC to request a leg to be joined to a connection point. Join implies through-connect of reserved communication resources in the ATM network.
modify_leg: This message is sent from SC to CC to request modification of QoS for a leg.
split: This message is sent from SC to CC to request a leg to be split from a connection point. Split implies disconnect of associated communication resources.
free_leg: This message is sent from SC to CC to request a leg and all associated resources to be released. Free_leg implies release of associated communication resources.
free_cp: This message is sent from SC to CC to request a connection point and all associated resources to be released.
close_socket: This message is sent from SC to CC to indicate the termination of a session.
Due to limited signal multiplexing capability in the ATM trial network, some restrictions are put on the possible combinations of legs and connection points:
This section gives a more detailed description of the overall control architecture introduced in chapter 2. A service example is used to illustrate the role and functionality of the two control domains.
B-ISDN is likely to extend the range of services offered by ISDN considerably. The ATM network provides flexible bandwidth allocation mechanisms enabling a variety of multiconnection/multiparty services. To offer these services, the following call handling capabilities seem to be necessary:
Below follows a service scenario including these call handling capabilities. The scenario involves Rosemary, her little baby, doctor Smith (the family doctor) and doctor Jones (a dermatologist).
Rosemary's baby has been crying all night, and Rosemary suspects that it has something to do with the red spots appearing several places on her skin. Maybe it is some kind of itchy skin eruption? Rosemary decides to call a doctor to hear his opinion. She carries the baby to the videophone, and calls doctor Smith, the family doctor. "It's a nice thing this videophone", she thinks. "It's much easier to just show the problem to the doctor instead of trying to explain it. Now, maybe doctor Smith can order some treatment directly?"
Doctor Smith, however, feels uncertain. "There are so many kinds of skin problems these days, it's impossible for me to keep up", he says, "I'd better call a specialist. Don't hang up!" Doctor Smith temporarily parks the call to Jane and makes a voice call to doctor Jones. To keep the communication costs as low as possible, doctor Smith always tries to avoid using picture when it is not really necessary. After explaining the problem to doctor Jones, doctor Smith returns to Rosemary. "I shall connect you to doctor Jones. He is much better skilled to take care of your problem."
When doctor Jones gets the picture of Rosemary's baby on the screen, the first thing he does is to press a button that gives him an improved quality video picture. "It's a good thing you have a modern videophone that can supply high quality video", he tells Rosemary. "With only standard quality video, it's not possible to tell one skin eruption from the other." Doctor Jones decides that Rosemary can treat the baby's skin herself, using healing ointment and bactericidal baths. Doctor Jones calls the new medical video database. He knows he can get a video clip there, illustrating how the treatment is to be done. He identifies the video clip, and orders it to be displayed both to himself and to Rosemary, giving him the opportunity to supplement the illustrated treatment.
Assume doctor Smith has a UPT (universal personal telecommunication) subscription. Rosemary dials his UPT number (logical address), SC starts processing the service request, detects the address to be a UPT address and checks a database to find the physical address of doctor Smith's present location. SC now knows where to place the call.
Rosemary has requested a videophone call (standard quality video and speech) to doctor Smith. SC therefore checks if doctor Smith has the requested terminal capabilities at his present location and is free to accept the call. As part of this phase, SC negotiates the required quality of service (QoS) between the two end-user terminals. If the terminals are equipped with different video codec standards, it may be necessary for SC to involve an interworking unit in the network capable of handling the translation from one video codec standard to the other. In our example we assume the two terminals to be compatible, thus no interworking unit is needed.
Note that number translation and Quality of Service negotiation are performed by SC. CC gets involved (a connection control socket is opened) first after knowing the physical location and terminal capabilities of doctor Smith. At this point SC requests CC to create two connection points for the call. Next, SC requests creation of two sets of bidirectional point-to-point legs; one set for speech and one set for video. At this stage in the call, the communication paths from Rosemary to doctor Smith are reserved, but not through-connected. This implies that information is not allowed to flow between the two end-users yet.
The following sequence of requests are used for reserving the speech and video part: open_socket create_cp (cp1)
create_leg (cp1, leg1, speech, bidirectional, Dr Smith)
create_leg (cp1, leg2, speech, bidirectional, Rosemary)
create_cp (cp2)
create_leg (cp2, leg3, video, bidirectional, Dr Smith)
create_leg (cp2, leg4, video, bidirectional, Rosemary)
Rosemary receives an alerting indicating that the phone is ringing at doctor Smith's. Detecting that doctor Smith picks up the phone, SC requests each pair of legs to be joined to their associated connection points. The following sequence of messages is sent from SC to CC to through-connect the speech and video part:
join (leg1)
join (leg2)
join (leg3)
join (leg4)
This causes the call to be through-connected and the two persons may communicate with each other via their videophone terminals. Figure 9 shows the through-connected speech and video connections.
Later, doctor Smith puts the call from Rosemary on hold and calls the dermatologist, doctor Jones. As a consequence, SC tells CC to split the speech and video legs from Rosemary and the video leg from doctor Smith and to set up a new speech leg towards doctor Jones. The following messages are sent from SC to CC:
split (leg2)
split (leg4)
split (leg3)
create_leg (cp1, leg5, speech, bidirectional, Dr Jones)
join (leg5)
Although the connections between Rosemary and doctor Smith are disconnected, the call is not released and the network resources are still reserved. Figure 10 shows the present situation.
After having consulted doctor Jones, doctor Smith returns to Rosemary. He says goodbye and transfers her call to doctor Jones. As a result, SC requests all legs to doctor Smith to be released. The following sequence of messages is sent from SC:
split (leg5) #Doctor Smith returns to # Rosemary
join (leg2)
free_leg (leg1) #Rosemary is transferred # to doctor Jones
free_leg (leg3)
create_leg (cp2, leg6, video, bidirectional, Dr Jones)
join (leg4)
join (leg5)
join (leg6)
Doctor Jones realises that he needs a much better picture quality to be able to make a thorough examination of the baby's skin eruption. This calls for a renegotiation of the quality of service between the two end- users for the video part of the communication. If both terminals are capable of supporting high quality video, the following messages are sent from SC to CC:
modify_qos (leg4, video_high)
modify_qos (leg6, video_high)
After having identified the type of skin eruption, doctor Jones calls the medical video database and orders the video clip demonstrating the treatment to be presented to Rosemary and himself. The video part of the communication between Rosemary and doctor Jones is now released and a new unidirectional point-to-multipoint communication path is set up from the video database to Rosemary and doctor Jones. In order to do this, the following sequence of messages are sent from SC to CC:
free_leg (leg4)
free_leg (leg6)
free_cp (cp2)
create_cp (cp3)
create_leg (cp3, leg7, video, upstream, VideoDB)
create_leg (cp3, leg8, video, downstream, Rosemary)
create_leg (cp3, leg9, video, downstream, Dr Jones)
join (leg7)
join (leg8)
join (leg9)
The speech part between Rosemary and doctor Jones is still through- connected in order for doctor Jones to explain the different steps of the treatment. Figure 12 shows the three-party configuration with video distribution.
The task of CC is to set up, release and manipulate connections in the ATM network, making as efficient use of the network resources as possible. To show what this implies, we will first look in some detail at how the first speech connection is set up, and then extend the picture by looking at a couple of three party configurations. We assume the network configuration shown in Figure 13. Note that in this example, SC interacts with the CC node running in Rosemary's local exchange (exchange A).
The sequence of requests needed from SC to set up the initial speech connection was given in section 3.2 and is repeated below.
create_cp (cp1)
create_leg (cp1, leg1, speech, bidirectional, Dr Smith)
create_leg (cp1, leg2, speech, bidirectional, Rosemary)
join (leg1)
join (leg2)
The create_cp message defines a connection point reference.
When the first create_leg message is received, CC-A starts allocating network resources corresponding to this leg. Since this is a bidirectional leg, two virtual channel connections from exchange A to doctor Smith's terminal are required, one in each direction.
Each of the CC nodes participating in the connection establishment performs the same procedure, in our implementation consisting of three main steps:
Algorithms for routing and resource allocation in an ATM network is currently being developed in international organisations and research laboratories, including NTR (2, 3).
In our current implementation we have chosen a very simple routing method. Routing implies identifying the next physical link to be used for the connection, the identified link leading directly to the destination terminal or to another exchange.
The two needed virtual channel connections are created in parallel with identical routes.
The set of possible links is found by looking up in a static routing table. Only links with available bandwidth are considered. The links are ranked according to number of hops to the destination address. This number is found in the routing table. A link is selected according to the following rules:
1 The link with the lowest number of hops is preferred.
2 If several links have equal number of hops, one of them is arbitrarily chosen.
If, as in this case, two virtual channel connections are needed, they are always created in parallel, with identical routes. This constraint only complicates the described routing algorithm slightly. The motivation for this decision is explained below.
Once the physical links have been chosen, the internal data structures of the CC node is updated, to reflect that the required bandwidth on the links have been reserved.
VCI negotiation implies that the CC node exchanges messages with the neighbouring CC node or terminal to reach an agreement on the VCI values to be used on the selected physical links.
As explained in section 2.1, the main function of the switch is to interconnect incoming virtual channel links with outgoing virtual channel links. When the VCI negotiation is completed and the virtual channel links are successfully established, the CC node completes its task by setting up the connections through the switch. The connections are only reserved through the switch, not through-connected. User information is not allowed to flow on the connections until the appropriate join messages are issued by SC.
Note that CC-A is not able to set up connections through its switch when the first leg is created, since the switch at this point in time is an end- point for the connections.
Eventually, the connections will reach doctor Smith's terminal, completing the actions resulting from the first create_leg message.
The second create_leg message from SC makes CC set up virtual channel connections to Rosemary's terminal.
To summarise, the result of the first four messages is reservation of all network resources necessary for the communication to take place between doctor Smith and Rosemary (i.e. a point-to-point bidirectional connection).
The effect of the join messages is through-connect of the connections in the switches. This will open for the flow of user information on the connections. When the first join message is received, CC-A only stores the join request. Since, in general, more than two legs may be allocated to the connection point, CC does not have enough information to perform through-connect until it has two end-points, i.e. two joined legs. Thus, when the second join message is received, the virtual channel connections will be through-connected in all switches. The CC nodes will act on response of a connect message, which is created by CC-A, and travels through all CC nodes along the route.
The resulting configuration is illustrated in Figure 14. Voice communication can now take place. The video connections are established in a similar way (not shown).
To illustrate how CC supports configurations with more than two legs allocated to a connection point, we turn to what happens as doctor Smith temporarily puts the connection to Rosemary on hold in order to consult doctor Jones.
This example shows how the constraint that only two bidirectional legs may be joined to a connection point is used by CC to reduce the number of virtual channel links allocated. The idea is that several legs may share the same virtual channel links. The point-to-multipoint and multipoint-to- point capabilities of the switch, as well as the capability of differentiating between reserved and through-connected connections are also necessary ingredients in this solution.
The following sequence of messages are sent from SC to CC (again, only showing the speech part):
split (leg2)
create_leg (cp1, leg3, speech, bidirectional, Dr Jones)
join (leg3)
The split message triggers the reverse operation of the previous join, i.e. the virtual channel connections are disconnected (i.e. returned to the reserved state) in all the switches. User information (speech) can no longer flow between Rosemary and doctor Smith. All network resources remain reserved, however.
The procedure for connection establishment was described above. When the create_leg message for leg3 is received, this procedure is performed again. This time, however, some additional points can be made. The result of the routing step in CC-A, makes it clear that B is the most suitable next node, i.e. a virtual channel link from A to B is needed. There is, however, already allocated a virtual channel link from A to B, for leg1. As pointed out above, there is no reason to allocate a second one. If a second link was allocated, the constraint of maximum two joined legs (i.e. point-to-point communication) implies that at any point in time, at most one of them would be used.
The resulting configuration is shown in Figure 15. Only one link is allocated between switches A and B. Note that through switch B, each of the three incoming virtual channel links are connected with two outgoing links. Thus, both point-to-multipoint, and multipoint-to-point relations are found. Note that this rather complex situation is only reserved, not through-connected. The point is that sufficient network resources have now been reserved for any pair of partners to communicate.
As mentioned above, the two virtual channel connections allocated to realise a bidirectional leg are always routed the same way (in parallel). The reason is seen from the example. If the two connections between Rosemary and doctor Smith had been routed separate ways when the first two legs were created, the idea of different legs sharing links would be considerably more difficult to realise.
The last join message implies that user information should be enabled between the doctors Smith and Jones. The connections are thus through- connected in the switches C and E, as well as the appropriate parts of the complex connections in switch B, as shown in Figure 15.
Finally, to illustrate how the video distribution configuration is realised in terms of ATM virtual channel connections; we move to the point in the call where doctor Jones decides to use the video database. SC requests the bidirectional video connection point and associated legs to be deleted (using free_leg and free_cp messages), and requests a unidirectional connection point with associated legs to be created. The message sequence is as follows:
create_cp (cp3)
create_leg (cp3, leg7, video, upstream, VideoDB)
create_leg (cp3, leg8, video, downstream, Rosemary)
create_leg (cp3, leg9, video, downstream, Dr Jones)
join (leg7)
join (leg8)
join (leg9)
The actions performed by CC as the messages are received, follow the scheme explained above, and will not be repeated here. The resulting configuration is shown in Figure 16.
In the trial network, one CC node is controlling one ATM switch. The CC node interfaces other CC nodes, SC nodes and control software in CPNs and end-user terminals. The signalling network interconnecting different control nodes is implemented by standard Ethernet, while the CC nodes are implemented in Sun workstations. Figure 5 shows the physical configuration of the control system.
This section gives a more detailed description of the software in one CC node. A flexible and simple structure, picturing the underlying switching system, is obtained by applying object oriented principles. In our implementation, OORASS (5), an object oriented modelling method is combined with the programming language Eiffel. (4)
Figure 17 shows the basic object types in a CC node and their interconnection, Figure 18 contains supplementary object descriptions and Figure 19 shows a message flow scenario. The message flow scenario shows the object interaction needed to reserve the speech leg towards doctor Smith (leg1 in our service example). To simplify the message flow scenario, objects handling communication across external interfaces are not included. In the figures the term message is used in the object- oriented sense, i.e. to "send a message to an object" means the same as "request a service" or "invoke an operation" on it.
As seen from Figures 17 and 18, transport problems are encapsulated in the Signalling Transport and Switch objects. To avoid looking at B-ISDN signalling protocols in our first prototype, the Ethernet is used for signalling transport. An integration of signalling traffic in the ATM network requires updated functionality in the Signalling Transport and Switch objects, but has no impact on the overall object model. Thus, our CC model is independent of the signalling network chosen.
The B-ISDN connection control system at Norwegian Telecom Research offers powerful and flexible handling of various connection configurations needed to support B-ISDN services. The use of IN concepts and object oriented principles have made this possible.
By adopting the virtual switch concept in the Connection Control Socket Model developed by ETSI/NA6, our control system fulfills some of the main IN objectives:
As described, the CC domain performs the mapping from legs and connection points to ATM connections and physical switching points. An efficient use of network resources seems to be obtained by
To focus on the functionality of the connection control system and avoid looking into B-ISDN signalling protocols, standard Ethernet has been used as a dedicated signalling network. However, our CC model decouples completely signalling and transport aspects, and an integration of the signalling traffic in the ATM network will have no impact on the software structure in a CC node.
1 ETSI DTR/NA-6001. Draft Technical Report, Intelligent Network: Framework, Version 2. September 1990.
2 Hemmer, H et al. Trafikkfunksjoner i ATM-nett. Kjeller, Norwegian Telecom Research, 1992. (TF N1/92.)
3 Pettersen, H. Dirigering og ressursallokering i ATM-nett. Kjeller, Norwegian Telecom Research, 1990. (TF F23/90.)
4 Meyer, B. Object-oriented software construction. Englewood Cliffs, N-J., Prentice-Hall, 1988. ISBN 0-13-629031-0.
5 Reenskaug, T et al. OORASS: Seamless Support for the Creation and Maintenance of Object Oriented Systems. Oslo, Taskon, 1991.
6 Handel, R et al. Integrated broadband networks: An introduction to ATM-based networks. Reading, Mass., Addison-Wesley, 1991. ISBN 0-201-54444-X.
7 CCITT Recommendation I.150. B-ISDN ATM Functional Characteristics. Geneva, 1991.
8 CCITT Recommendation I.211. B-ISDN Service Aspects. Geneva, 1991.
9 CCITT Recommendation I.311. B-ISDN General Network Aspects. Geneva, 1991.