home *** CD-ROM | disk | FTP | other *** search
Text File | 1993-06-28 | 23.2 KB | 1,199 lines |
- 2. SECTION 2 - REFERENCE MODELS
-
-
-
- 2.1 Recommendation I.320
-
-
-
-
-
- ISDN PROTOCOL REFERENCE MODEL
-
-
-
-
-
- 1. Introduction
-
-
-
- The objective of the ISDN Protocol Reference Model (ISDN PRM) is to model the interconnection and exchange
- of information - including user information and control information - to, through or inside an ISDN.
-
-
-
- Communicating entities may be:
-
-
-
- - ISDN users;
-
- - an ISDN user and a functional entity within an ISDN, e.g. network control facilities;
-
- - an ISDN user and a functional entity inside or outside an ISDN, e.g. an information storage/processing/
- messaging facility;
-
- - various functional entities in an ISDN, e.g. a network management facility and a switching facility;
-
- - an ISDN functional entity and an entity located in or attached to a non-ISDN network.
-
-
-
- The purpose of communications between these functional entities is to support the telecommunication ser-
- vices introduced in Recommendations I.211 and I.212, by providing ISDN capabilities as defined in Recommenda-
- tion I.310. Examples of these capabilities are:
-
-
-
- - circuit-switched connection under the control of common channel signalling;
-
- - packet-switched communication over B-, D- and H-channels;
-
- - signalling between users and network-based facilities (e.g. information retrieval systems such as
- Videotex, operations data bases such as directory);
-
- - end-to-end signalling between users (e.g. to change mode of communication over an already
- established connection);
-
- - combinations of the above as in multi-media communication, whereby several simultaneous
- modes of communication can take place under common signalling control.
-
-
-
- With such diversity of ISDN capabilities (in terms of information flows and modes of communication), there is
- a need to model all these capabilities within a common framework (i.e. reference model). This would enable the
- critical protocol architectural issues to be readily identified and facilitate the development of ISDN protocols and
- associated features. It is not intended as a definition of any specific implementation of an ISDN or of any systems
- or equipment in, or connected to, an ISDN.
-
-
-
- Examples of applications of this model are included in this Recommendation.
-
-
-
- 2. Modelling concepts
-
-
-
- 2.1 Relationship with the X.200-Series
-
-
-
- The ISDN Protocol Reference Model (PRM) and the Reference Model of Open Systems Interconnection for CCITT Appli-
- cations (OSI RM), defined by Recommendation X.200, have both commonalities and differences.
-
-
-
- Both the ISDN PRM and the OSI RM organize communications functions into layers and describe the relation of these
- layers with respect to each other. However, the scope of the ISDN PRM is different from the scope of the OSI RM.
-
-
-
- The scope of the ISDN PRM is to model information flows across the range of telecommunication services defined in
- the I.200-Series. These are Bearer Services, Teleservices and Supplementary Services. This description necessarily incor-
- porates ISDN-specific characteristics not encountered in other network types. Among these characteristics are multi-
- service types of communications which include voice, video, data and multi-media communications.
-
-
-
- The scope of the OSI RM is not associated with any particular network type1. In that sense it is less specific than the
- ISDN PRM. Further, the scope of the OSI PRM is tied to data communications and so, in that sense, its scope is more
- specific than the ISDN PRM. The OSI PRM - that application is to model data communications between open systems in
- an ISDN environment.
-
-
-
- The relative scopes of the two models are illustrated by Figure1/I.320. The existence of a common intersection shows
- that these models coexist and overlap.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 1/I.320
-
-
-
- Applicability of OSI protocols to ISDN
-
-
-
-
-
-
-
-
-
- ûûûûûûûûûûûû
-
- 1 Note that the term "network" in the ISDN corresponds to "sub-network" in the OSI terminology.
-
-
-
- However, in spite of these differences in scope, a number of concepts and the associated terminology which have
- been introduced in
-
- Recommendations X.200 and X.210 are fully applicable to the ISDN PRM. They include the concept of layer, layer service
- (X.200), and the notions of service primitive, peer entity and peer protocol (X.210).
-
-
-
- Note - The relation between service primitives and functional components introduced in Recommendation I.310 requires
- further study.
-
-
-
- The layer identification used in Recommendation X.200 is limited in this Recommendation to the use of layer num-
- bers. Layer titles (e.g. network layer) as used in Recommendation X.200 are sometimes misleading in the ISDN context,
- and have not been used here.
-
-
-
- The following ISDN needs have to be specifically catered for in Recommendation I.320:
-
-
-
- - information flows for out-of-band call control processes, or more generally, information flows among mul-
- tiple related protocols;
-
- - information flows for selection of connection characteristics;
-
- - information flows for re-negotiation of connection characteristics of calls;
-
- - information flows for suspension of connections;
-
- - information flows for overlap sending ;
-
- - information flows for multi-media calls;
-
- - information flows for asymmetric connections;
-
- - information flows for network management (e.g. change over and change back) and for maintenance func-
- tions (e.g test loops);
-
- - information flows for power activation/deactivation;
-
- - interworking;
-
- - switching of information flows;
-
- - new layer service definitions for non-data services;
-
- - application to other than end-systems, e.g. signal transfer points (STPs) and interworking points;
-
- - information flows for multi-point connections;
-
- - information flows for applications such as:
-
- - voice (including A/╡ law conversion),
-
- - full motion video,
-
- - transparent,
-
- - telex.
-
-
-
- 2.2 Control and user planes
-
-
-
- The support of outband signalling, the ability to activate supplementary services during the active phase of
- the call, imply a separation between control information and user information.
-
-
-
- The notion of plane - control plane, or C-plane, and user plane, or U-plane - is introduced to reflect this.
-
-
-
- The main rationale for protocols within the user plane is the transfer of information among user applications,
- e.g. digitized voice, data and information transmitted between users. This information may be transmitted trans-
- parently through an ISDN, or it may be processed or manipulated, e.g. A/╡ conversion.
-
-
-
- The main rationale for protocols within the control plane is the transfer of information for the control of user
- plane connections, e.g. in:
-
-
-
- - controlling a network connection (such as establishing and clearing down);
-
-
-
- - controlling the use of an already established network connection (e.g. change in service characteristics
- during a call such as alternate speech/unrestricted 64 kbit/s);
-
-
-
- - providing supplementary services.
-
-
-
- In addition to user information, any information which control the exchange of data within a connection, but
- otherwise do not alter the state of this connection (e.g. flow control), pertain to the U-plane. All control infor-
- mation which involve resource allocation/deallocation by the ISDN pertain to the C-plane.
-
-
-
-
-
- 2.3 Local and global significance
-
-
-
- A key characteristic of the ISDN is that, due to the integration of telecommunication services, the facilities to
- be provided depend on whether the adjacent entity, or a remote entity, is involved: different services, possibly
- using different routes, may have to be provided accordingly. An example is a telecommunication service, which
- can be supported by various network capabilities, (e.g. a telematic service supported either by circuit or
-
- packet facilities), or an ISDN connection based on various types of basic connection components (e.g. analogue
- and digital circuits for a speech connection).
-
-
-
- As a consequence, the control information handled by an entity may concern:
-
-
-
- - an adjacent functional entity, in which case it is said to have local significance;
-
-
-
- - a remote (non-adjacent) functional entity, in which case it has global significance.
-
-
-
- The significance concept is illustrated by Figure 2/I.320
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Local
-
- <----------------->
-
- Global
-
- <-------------------------------------->
-
-
-
- OE = Originating Functional Entity
-
-
-
- AE = Adjacent Functional Entity
-
-
-
- RE = Remote Functional Entity
-
-
-
- FIGURE 2/I.320
-
-
-
- Significance
-
-
-
- The notion of significance applies to control plane information only.
-
-
-
- As an example:
-
-
-
- - from the ISDN user's point of view:
-
-
-
- - the overall service to be provided to users has a globalsignificance;
-
-
-
- - the control of any resources to be used at the user-network interface has local significance;
-
-
-
- - from the network's point of view:
-
-
-
- - the overall service to be provided by the ISDN (ISDN connection types, as introduced in
- Recommendation I.340) has a global significance;
-
-
-
- - the handling of connection elements, has local significance.
-
-
-
- Depending on their functional requirements, supplementary services relate to either the local, or global per-
- spective. For example:
-
-
-
- - CCBS or user-to-user signalling have global significance;
-
-
-
- - call waiting has local significance.
-
-
-
- Global information falls into three classes:
-
-
-
- 1) the information is transported transparently;
-
-
-
- 2) the information may be processed, but remains unchanged (e.g. teleservice);
-
-
-
- 3) the information may be altered (e.g. destination number in relation with freephone or call forwarding
- supplementary services).
-
-
-
- 3. The model
-
-
-
- The ISDN protocol reference model (PRM) is represented by a protocol block which incorporates the concepts
- of layer, significance and plane described hereabove.
-
-
-
- Such a protocol block can be used to describe various elements in the ISDN user premises and the network (e.g. ter-
- minal equipment (TE), ISPBX network termination (NT), exchange termination (ET), signalling point (SP) and signalling
- transfer point (STP), etc.).
-
-
-
- 3.1 Generic Protocol Block
-
-
-
- The considerations above lead to the introduction of the concept of significance in combination with planes; the result
- is a splitting of the control plane into two parts: a local control plane (LC), and a global control plane (GC), in addition to
- the user plane (U).
-
-
-
- The layering principles apply in each of these planes: each plane can potentially accommodate a 7-layer stack of pro-
- tocols. A plane management function is required to allow coordination between the activities in the different planes. Exam-
- ples of plan management function are:
-
-
-
- - the decision on whether an incoming information is relevant to
-
- the LC or GC plane,
-
-
-
- - allowing communication between C- and U-planes, for synchronization purposes.
-
-
-
- The Generic Protocol Block is represented on Figure 3/I.320.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 3/I.320
-
-
-
- Generic Protocol Block
-
-
-
- Note - The Plane Management Function should not be confused with the System Management as introduced to model OSI
- management.
-
-
-
- The following remarks apply:
-
-
-
- 1) Some layers may be empty, i.e. they provide no functionality. For example, it is likely that not all seven layers
- are required to serve the LC-plane requirements; however, entities communicating in this plane are application layer enti-
- ties. Note that this is not in contradiction with the OSI RM.
-
-
-
- 2) An element (either in the network, or in user premises) does not have to support in all cases protocols of LC-
- , GC- and U-planes: some may ignore one or even two of these planes. For example, a network service centre accessed
- to provide a supplementary service (e.g. freephone) will be concerned by the LC plane only, and will have no knowledge of
- the other two planes.
-
-
-
- 3) A network element - unless it provides an HLF - will generally not support any U-plane protocol above layer 3.
-
-
-
- 4) The need for application processes specific to each plane, or for application processes able to access several
- planes, is for further study.
-
-
-
- 3.2 Relations between layers in one plane
-
-
-
- Adjacent layers within a plane communicate using service primitives. If a layer is empty the primitive is
- mapped directly onto a primitive to the next layer.
-
-
-
- Further study is required on which layer services have to be specified in order to describe a telecommunica-
- tion service.
-
-
-
- 3.3 Relations between planes
-
-
-
- Starting from GC-plane requirements, an entity will derive the LC-plane requirements, and the facilities that
- have to be provided for the support of U-plane lower layers. For example, in order to provide an ISDN connection
- (GC-plane), an exchange will have to identify the required basic connection component (LC-plane).
-
-
-
- This relation is made via the plane management function.
-
-
-
- Informations in different planes need not be carried by distinct physical/logical means in all cases. For
- example:
-
-
-
- - control and user informations may use the same support, e.g. when inband signalling is used, or when
- user information is carried on a D-channel;
-
-
-
- - LC and GC informations share the same support when the LC-plane pass-along facility is used;
-
-
-
- - ISPBX to ISPBX control information appears as U-plane information to the ISDN.
-
-
-
- 3.4 Data flow modelling
-
-
-
- For further study.
-
-
-
- 4. ISDN management
-
-
-
- For further study.
-
-
-
- 5. Interworking
-
-
-
- A number of particular interworking situations should be considered:
-
-
-
- - internetworking with an OSI network;
-
-
-
- - interworking with an non-ISDN terminal;
-
-
-
- - interworking between two ISDNs which do not provide the same set of facilities;
-
-
-
- - interworking involving a network-provided interworking function to support high-layer and/or low-layer
- facilities.
-
-
-
- 5.1 General
-
-
-
- All the interworking situations mentioned above are covered by the model illustrated by Figure 4/I.320.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 4/I.320
-
-
-
- Interworking Model
-
-
-
- (1) Note - This reference point is an S/T reference point when considering interworking between ISDNs, or service
- interworking within an ISDN.
-
-
-
- The service S may be:
-
-
-
- - the initially required telecommunication service (TS), if both networks are able to provide it (F is then
- empty);
-
-
-
- - a telecommunication service resulting from a negotiation process, which both networks are able to provide
- (F is then empty);
-
-
-
- - a service which is required to support the telecommunication, service to be provided, which is offered by
- both networks, but by means of different capabilities in the two networks.
-
-
-
- The service S is provided:
-
-
-
- - by means of functions F1 and protocol(s) P1 in network 1;
-
-
-
- - by means of functions F2 and protocol(s) P2 in network 2.
-
-
-
- The interworking function (IWF) maps the facilities offered by F1 and F2.
-
-
-
- Two kinds of interworking can take place:
-
-
-
- 1. a one-stage interworking, where the calling user is not explicitly aware that an interworking function is
- required;
-
-
-
- 2. a two-stage interworking, where the calling user has a dialogue with the interworking function prior to
- exchanging control information with the destination user.
-
-
-
- The model applies to both cases.
-
-
-
- Interworking may involve the GC-plane, and/or the U-plane.
-
-
-
- In an interworking situation, the GC-plane has to:
-
-
-
- - determine the telecommunication service to be provided (agreed telecommunication service): this may
- imply service negotiation;
-
-
-
- - identify the interworking situation, i.e. the fact that more than one network is involved, and that for some
- service S required to support the telecommunication service, two adjacent networks do not use the same
- underlying facilities;
-
-
-
- - locate and invoke an IWF capable of mapping the facilities in the two networks.
-
-
-
- In each network, the GC-plane facilities will provide the functions and protocols (Fi and Pi) required to support ser-
- vice S; this will result in different (and independent) requirements on the CL-plane in each network.
-
-
-
- In the two-stage interworking case, the GC-plane information is "consumed" by the IWF during the first phase, and
- is forwarded (with or without modification) during the second one.
-
-
-
- Whenever interworking in the U-plane is involved the following differences apply in the two cases:
-
-
-
- - one-stage interworking: in this case only the first three layers (at most) may be involved for the provision of
- the requested
-
- end-to-end service. No HLF is required.
-
-
-
- - two-stage interworking: in this case the first stage is the establishment of the U-plane facilities between
- the calling user and the IWF. High layer functions (HLF) and protocols may be involved, in which case the
- IWF acts as a substitute for the called user.
-
-
-
- 5.2 Relationships with the OSI RM
-
-
-
- The OSI RM, seen from the ISDN PRM point of view, appears not to be in contradiction with the latter, but contains
- some restrictions which stem from the fact that it does not have the same scope:
-
-
-
- 1) The C- and U-planes are not separated, since the C- and U-plane information in one layer (n) always maps
- onto the U-plane information of the layer below (n - 1).
-
-
-
- 2) The concept of significance does not explicitly appear; however control informations (e.g. in layer 3) include
- both 'local' informations and informations which are carried end-to-end transparently or take part in
- the definition of the overall service provided to the user (e.g. throughput).
-
-
-
- 3) The C- and U-plane informations in one layer (n) map onto the
-
- U-plane informations of the layer below (n - 1).
-
-
-
- Interworking between the OSI RM and ISDN PRM takes place in the following situations:
-
-
-
- - internetworking with a specialized network (e.g. PSPDN) which respects the OSI RM: the reference points
- involved are K/L;
-
-
-
- - interworking with an "OSI terminal" via a terminal adaptor: the reference point is then R;
-
-
-
- - the interworking of an ISDN terminal on the S reference point which conforms to the OSI reference
- model is for further study.
-
-
-
- In each case, the interworking function (an IWF or a TA) has to map information flows of one model onto
- information flows of the other.
-
-
-
- 5.2.1 Interworking at reference point K/L
-
-
-
- For further study.
-
-
-
- 5.2.2 Interworking at reference point R
-
-
-
- In the case when a user application, running an OSI system, requires network services across the ISDN, the
- originating user application will address the terminating application as a destination user.
-
-
-
- In the OSI system, the application is considered an an ISDN user - a communicating functional entity in the
- PRM.
-
-
-
- The GC information pertinent to the higher layer OSI application is carried in the U-plane to the destination
- application. The GC information pertinent to the network service required is carried in the control plane with LC
- control information.
-
-
-
- The OSI system requests the network service from the ISDN by placing a service request to both the LC plane
- and the U-plane (Figure 5/I.320). The distribution of the information to the appropriate planes is made by the
- Plane Management Function. The Plane Management Function is responsible for providing an OSI Service Access
- Point to the OSI system.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Figure 5/I.320
-
-
-
- OSI Reference Model and ISDN Protocol Reference Model
-
-
-
-
-
- 6. Examples
-
-
-
- Applications of the PRM to the following examples is for further study.
-
-
-
- 6.1 Basic call situations (no supplementary service, no interworking)
-
-
-
- - circuit service (see Figure 6/I.320)
-
-
-
- - packet service
-
-
-
- - multi-bearer capability
-
-
-
- - data base access.
-
-
-
-
-
- 6.2 More elaborate situations
-
-
-
- - supplementary services
-
-
-
- CCBS
-
- 3-party service
-
-
-
- - PABX facilities
-
-
-
- - OA&M applications.
-
-
-
- 6.3 Interworking
-
-
-
- - at reference point R (Teletex terminal)
-
-
-
- - with a PSTN
-
-
-
- - with a PSPDN (Videotex)
-
-
-
- - inside an ISDN (provision of an HLF by the network).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Legend:
-
-
-
- C - Local or Global Control depending on the destination functional entity
-
-
-
- LC - Local Control
-
-
-
- GC - Global Control
-
-
-
- M - Plane Management Function
-
-
-
- NU - Network User Plane
-
-
-
- PU - PSN User Plane
-
-
-
- TU - Terminal User Plane
-
-
-
- Note - For simplicity reasons, NTI functional units are not shown.
-
-
-
- FIGURE 7/I.320
-
-
-
- A protocol reference model example showing the underconnection of
-
- public and private ISDNs
-
-
-
-
-
- Function of a functional entity to support layers 1 and 2 of the user-network signalling system.
-
-
-
- 305 inter-exchange signalling handling (message transfer)
-
-
-
- Function of a functional entity to support the messages transfer part of the inter-exchange signalling systems.
-
-
-
- 306 path search inside switching unit
-
-
-
- Function of a functional entity to select an internal connection inside the switching unit.
-
-
-
- 307 synchronization handling
-
-
-
- Function of a functional entity to provide synchronization between different functional entities; and:
-
-
-
- Function of a functional entity to provide its own internal synchronization functional entity.
-
-
-
- 308 Timing handling
-
-
-
- Function of a functional entity to provide timing between time instances involved in calls.
-
-
-
- 309 line service marking
-
-
-
- Functions of a functional entity to store for each customer the data on the parameters of the bearer and teleservices
- that are subscribed to. The store also contains the data on the parameters of the basic bearer and teleservices that are
- subscribed to by the customer. It also contains the binary information (i.e. subscribed to or not) for a range of sup-
- plementary service which the subscriber can use. In general this data does NOT contain information on the type of sub-
- scriber's terminal, but it may contain information on the type of access (basic, primary rate, etc.), the type of NT2
- (simple, intelligent, etc.) and the attributesof the services subscribed to.
-
-
-
- 310 real time clock
-
-
-
- Function of a functional entity to provide real time information.
-
-
-
- 4 SUPERVISION
-
-
-
- 400 user-network access resources monitoring
-
-
-
- Function of a functional entity to check the correct operation of subscriber access resources.
-
-
-
- 401 transit resources monitoring
-
-
-
- Function of a functional entity to check the correct operation of the transit resources.
-