delim @@
|
| 5i' |
||||
|
PART III I.300-Series Recommendations |
||||
|
OVERALL |
NETWORK ASPECTS AND FUNCTIONS |
|||
|
Blanc |
MONTAGE: PAGE 2 = PAGE BLANCHE 2 Fascicle III.8 -- Rec. I.310
SECTION 1
NETWORK FUNCTIONAL PRINCIPLES
ISDN -- NETWORK FUNCTIONAL PRINCIPLES
(Malaga-Torremolinos, 1984; amended at Melbourne, 1988)
1.1 Basic philosophy of the functional description
The objective of this Recommendation is to provide a common understanding of the ISDN capabilities, including terminal, network and specialized service centre aspects.
A functional description of ISDN capabilities must allow a clear distinction between definition/specification aspects of services provided by the ISDN and the actual specification of the equipment utilized to support those services. Therefore, an implementation-independent approach should be adopted.
Moreover in the context of this Recommendation the adjective ``functional'' is used in the sense of an implementation-independent approach. The noun ``function'' itself has a specific meaning which is explained below.
The description of network capabilities is consistent with the protocol reference mode, e.g.:
-- the layering structure of all systems involved in a communication process, i.e. partitioning the required functions between different layers;
-- the clear discrimination between layer service concept, layer function concept and layer protocol concept.
|
Furthermore, the three following distinctions apply: -- distinction between basic services and supplementary services; -- distinction between ISDN capabilities and services offered to the customer; -- distinction between static and dynamic aspects of the description. |
||
|
1.2 |
Services supported by an ISDN The concepts and the principles of an ISDN are described in Recommendation I.120. The services supported by |
an ISDN are given in the I.200-Series of Recommendations. A classification and the tools for the description of telecommunication services are specified in Recommendation I.210 according to the description method as given in Recommendation I.130. The network capabilities to support these services are defined in the I.300-Series of Recommendations. The relationship between these Recommendations and some other relevant I-Series Recommendations is shown in Figure 1/I.310.
Fascicle III.8 -- Rec. I.310 3
Figure 1/I.310, (N), p.
It should be noted that the service concept defined in Recommendation I.210 is different from the layer service concept of the OSI model. The telecommunication service concept in Recommendation I.210 corresponds to the services offered to users by the network. Besides operational and commercial aspects, the provision of these telecommunication services (bearer and teleservices) and associated supplementary services requires the availability of appropriate capabilities:
|
1.3 |
-- -- -- |
network capabilities, in various network equipments (exchanges etc.); terminal capabilities; specialized service centre capabilities, when required. Generic description of required capabilities |
ISDN capabilities are the total sum of the functions required to support all basic and supplementary services offered by the ISDN.
1.3.1 Static description
The identification and characterization of these functions, which are related to the specification and analysis of these basic and supplementary services, form the first step of the generic description. This part of the generic description is intrinsically static.
1.3.2 Dynamic description
The use of a basic or supplementary service generally requires cooperation between functions located in different equipment.
The static description of the ISDN capabilities, which will be a list of functions, is not sufficient. It is necessary, in addition, to depict the sequence of events and the activation of functions coordinated by suitable inter-equipment signals. This second step is the dynamic aspect of the description. This involves firstly an identification and 4 Fascicle III.8 -- Rec. I.310
characterization of the functions and then a method of showing the dynamic interaction between functions.
Fascicle III.8 -- Rec. I.310 5
As described in Recommendation I.120, an Integrated Services Digital Network (ISDN) is a network providing end-to-end digital connectivity to support a wide range of telecommunication services.
The characterization of ISDN is centered on three main areas:
|
a) b) c) |
the standardization of services offered to users, so as to enable services to be internationally compatible; the stadardization of user-network interfaces, so as to enable terminal equipment to be portable [and to the standardization of ISDN capabilities to the degree necesary to allow user-network and |
network-network interworking, and thus achieve a) and b) above.
The I.200-Series of Recommendations identifies the range of telecommunication services to be offered in an ISDN, namely bearer services, teleservices, and associated supplementary services and the attributes characterizing those services. The I.400-Series of Recommendations describes both the functional and technical aspects of user-network interfaces. This Recommendation defines the ISDN capabilities to support services via interfaces in terms of functions. A functional description enables a decoupling of services and ISDN capabilities, and therefore allows an implementation-independent approach.
The principal objectives of the ISDN functional method are:
1) to define the ISDN capabilities, by building up a harmonized set of functions that are necessary and sufficient to support telecommunication services by their static and dynamic description;
2) to aid the evolution of ISDN capabilities (modifications, addition of capabilities to support new basic or supplementary services), by organizing this set of functions in an open-ended and modular structure;
3) to aid the standardization of system-independent switching functions between exchanges of differing designs and manufacture;
|
4) 5) |
to aid the standardization of interworking standards between switching systems located in different to provide information for the preparation of functional specifications for new telecommunication |
|
|
services; 6) |
to maximize the exploitation of functions provided and available in switching systems. |
The transition from an existing network to a comprehensive ISDN may require a period of time extending over one or more decades. Therefore the design of an ISDN will be revolutionary, adding capabilities in a flexible and modular manner. An ISDN may therefore be expected to provide an open-ended set of functional capabilities able to accommodate new needs as they arise at acceptable cost.
During a long intermediate period, some functions may not be implemented within a given ISDN. Also, specific arrangements should be used to ensure compatibility with existing networks and services. An ISDN should also give access to existing services and interwork with existing networks and terminals.
3.1 General concepts
The ISDN functional description defines a set of capabilities which enable bearer and teleservices to be offered to users (see Recommendation I.210). The services require two different levels of ISDN capabilities viz.:
-- the low-layer functions (LLF) relate to the bearer services;
6 Fascicle III.8 -- Rec. I.310
-- the high-layer functions (HLF) together with the lower layer functions relate to the teleservices.
In addition, operation and maintenance capabilities are required to support both bearer and teleservices (see Figure 2/I.310).
Fascicle III.8 -- Rec. I.310 7
Figure 2/I.310, (N), p.
The capabilities of the ISDN need a detailed and rigorous characterization because there is a wide range of standardization issues involved.
To achieve the functional objectives described in § 2, the ISDN functional description has been designed to:
-- define the overall functional characteristics of the ISDN;
-- be implementation-independent and place no constraints on national network architectures beyond the network and interface standards given in the I-Series of Recommendations;
-- take full account of the constraints of existing dedicated networks;
-- support the layering protocol concepts defined in Recommendation I.320.
For this purpose the concept of an ISDN function is used, which is defined as:
``A distiguishing characteristic which describes functional capabilities of a given equipment, or system, or network, as seen from the designer point of view.''
|
As far as possible, the number of functions should be limited. |
||
|
3.2 3.2.1 |
Static description model Global functions (GF) The description of ISDN capabilities concerns the low layers (1-3) in a global context (see Note), i.e. taking into |
account all the equipment involved in the communication, according to the protocol reference model. In this context, a global function is defined as:
-- referring to the ISDN capabilities;
-- having a global significance in the lower layers.
The set of all GFs leads to the description of the total ISDN low layer capabilities.
Note -- This concept of global function may be extended to describe the higher layer capabilities of ISDN terminals (and network capabilities, where these exist). In this case the GF has a global significance inside the higher 8 Fascicle III.8 -- Rec. I.310
layers.
Fascicle III.8 -- Rec. I.310 9
Figure 3/I.310, (N), p.
There are two kinds of GFs:
-- the Basic Global Functions (BGF), are those global functions needed to support ISDN basic services. The BGFs are related to ISDN connection types, as indicated in Table 1/I.310;
-- the Additional Global Functions (AGF), are related to the ISDN capability to support supplementary services. Details of the relationship between AGFs and the ISDN capability to support supplementary services are given in § 4.1.2.
3.2.2 Elementary functions (EF)
The introduction of the GF concept allows a general description of low layer capabilities.
The following is a more detailed description: for each GF, a set of elementary functions is identified as the set of basic elements which are then allocated to different functional entities involved in the communication.
GF = (EF1, EF2, EF3, . | | EFn)
An EF within this Recommendation is the lowest level of functionality. It is allocated to a functional entity involved in supporting a telecommunication service. An EF is an intrinsically static description of the capability of performing an action on a resource when defined conditions are met.
For building up a GF, each associated EF must be present in one or more functional entities of the ISDN. (In this context the ISDN may include the terminals, the network or specialized service centres.) But in a specific functional entity the complete set of associated EFs need not be present (see for example Figure 4/I.310).
Figure 4/I.310, (N), p. 10 Fascicle III.8 -- Rec. I.310
3.2.3 Allocation of EFs
This flexibility in construction of EFs allows a specialization of the functions to be allocated to particular functional entities. Because the Recommendations on the architecture of the ISDN (Recommendation I.324) will only specify a functional approach to standardization, the relationship between functional entities and specific equipment is, in general, a national matter. However an important first step in allocation of functions will be the distinction between terminal equipment and the network equipment involved.
Recommendation I.324 introduces the functional grouping CRF (connection related functions). The CRF can be local, national transit or international transit. EFs can be associated with each of these.
|
3.3 |
Dynamic description model The complete description of ISDN capabilities must include dynamic aspects involved in the process of a call. This association of functional and protocol aspects leads to the use of the following dynamic description method: |
|
|
3.3.1 |
Information flow diagrams The operation of basic and supplementary services are described and characterized, as seen from a network |
point of view, by using information flow diagrams which show the sequence of events occurring in the course of the call.
3.3.2 Executive processes
An executive process (EP) corresponds to the particular use of one or more elementary functions within a particular functional entity which always yields specific results. Therefore an EP is characterized by input information it needs for execution and by output information or actions resulting from execution.
Executive processes involve (see Figure 5/I.310):
a) sequences that link together events producing the activation of an EP, by means of signalling information passed between the function entities;
|
b) -- -- -- -- |
the information (or data) actually used: protocol information (signalling information sent or received by the component); component information (``network information''); static information (description of available resources, environment, services, etc.) dynamic information (elaborated and used during the call handling). |
The dynamic description of each basic or supplementary service as required in stage 2 of the description method given in Recommendation I.130, based on the above elements, results in a chart showing functional entities involved (e.g. associated with originating and destination exchanges, specialized service centres when required), the signalling information flow passed between them, and the executive processes used inside them.
The analysis of telecommunication services and technological development leads to the identification of the range of required functions.
The analysis of all the basic and supplementary services provided by the ISDN will lead to the establishment of a set of elementary functions which can be allocated to different functional entities.
Fascicle III.8 -- Rec. I.310 11
The design of a new basic or supplementary service should maximize the use of the set of existing EFs available to existing systems. This will minimize changes to the systems necessary for introducing these new services. The specifications for new equipment designed for providing particular services will have to comply with the set of EFs required for these services.
12 Fascicle III.8 -- Rec. I.310
Figure 5/I.310, (N), p. 5 4.1 Identification of ISDN global functions
4.1.1 Basic global functions (BGF)
The basic global functions correspond to the ISDN capability to provide the various connection types that support telecommunication services.
The functions implemented to support telecommunication services can be classified into the following categories:
-- Connection handling: | functions which enable the establishment (set-up), holding and release of connections (e.g. user-to-network signalling).
-- Routing: | functions that determine a suitable connection for a particular service (call) request, i.e. suitable paths between the various equipments and inside the switching systems to establish end-to-end connections (e.g. called number analysis).
-- Resources handling: | functions that enable the control of the resources necesary for the use of connections (e.g. transmission equipment, switching resources, data storage equipment).
-- Supervision: | functions that check the resources used to support the connections, to detect and signal possible problems and to solve them if possible (e.g. transmission error detection and correction).
-- Operation and maintenance: | functions providing the capability to control the correct working of the services/network as well for the subscribers as for the Administration.
-- Charging: | functions providing the capability to the Administration to charge the subscribers.
-- Interworking: | functions providing the capability for both service and network interworking.
-- Layer 2 and 3 data unit handling: | functions providing handling of layers 2 and 3 data units during the information transfer phase for the case of packet mode connections.
According to this classification, a basic global function is defined as:
-- referring to an ISDN connection type;
Fascicle III.8 -- Rec. I.310 13
-- belonging to one of the above categories.
Table 1/I.310 shows the total set of BGFs.
14 Fascicle III.8 -- Rec. I.310
H.T. [T1.310]
TABLE 1/I.310
ISDN basic global functions
center box; lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
|
{ Connection type Category } CT 1 CT 2 . | | CT n _ lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) . Connection handling 1 BGF 1 |
2 BGF 1 |
n |
BGF 1 _ lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) . Routing 1 BGF 2 2 BGF 2 n BGF 2 _ lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) . Resources handling 1 BGF 3 2 BGF 3 n BGF 3 _ lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) . Supervision 1 BGF 4 2 BGF 4 n BGF 4 _ lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) . Operation and maintenance 1 BGF 5 2 BGF 5 n BGF 5 _ lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) . Charging 1 BGF 6 2 BGF 6 n BGF 6 _ lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) . Interworking 1 BGF 7 2 BGF 7 n BGF 7 _ lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
|
{ Layer 2 and 3 data unit handling } 1 BGF 8 2 BGF 8 n BGF 8 _ |
|
|
Tableau 1/I.310, [T1.310], p. |
|
|
4.1.2 Additional global functions (AGF) |
The additional global functions corresponds to the ISDN capability to support supplementary services.
The classification of AGFs is based on the principle that the support of a supplementary service is considered as being realized by a number of functions distributed throughout the ISDN. The definition of AGFs needs further study.
4.2 Identification of ISDN elementary functions
Like GFs, there are two kinds of elementary functions: the basic EFs (i.e. components of BGFs, and possibly AGFs) and the additional EFs (i.e. components of AGFs). Therefore, identification of basic EFs requires a detailed analysis of connection types. Implementation and identification of additional EFs requires a detailed analysis of supplementary services implementation.
-- Basic EFs: | for each connection type, there are up to 8 BGFs to implement (see Table 1/I.310). Therefore each BGF is composed of basic EFs related to this connection type. However some basic EFs may be common to several connection types (e.g. ``called number analysis'' belonging to the BGF ``routing'').
-- Additional EFs: | additional EFs form a common set of functional elements available to build up the various AGFs, and thus to implement supplementary services.
Fascicle III.8 -- Rec. I.310 15
|
This grouping of EFs into sets of BGFs and AGFs is illustrated in Figure 6/I.310. The list of EFs so far identified is contained in Annex A, together with a preliminary set of definitions. Figure 6/I.310, (N), p. |
||
|
4.3 |
Identification of ISDN executive processes A possible use of the concept of an Executive Process (EP) is the definition of Functional Components (FC) as executive processes that |
can be invoked by the network to realize a telecommunication service.
According to this an FC is a specific example of how to use the EP concept.
A functional component is a set of elementary functions performed in an order that yields a specified result. An FC always has an invoking and a responding entity. The invoking entity is the entity which acts in response to an FC request from an invoking entity.
In defining an FC, the following guidelines should be considered:
-- FCs are used as building blocks and may be invoked in order to realize a telecommunication service. FCs will have signalling impact and should be structured in such a way that several telecommunication services can use them. In particular, the definition of an FC should as far as possible be independent of any connection type.
-- A new FC should not be defined if its functionality can be provided by one or more existing FCs. As an objective, an FC will not invoke another FC.
The relationship between an FC and EFs is shown in Figure 7/I.310.
16 Fascicle III.8 -- Rec. I.310
Figure 7/I.310, (N), p.
Once invoked, the responding entity will not be affected by unsolicited inputs from the invoking entity. However, the request for execution of an FC may be cancelled by the invoking entity if the request was received.
It should also be noted that the functionality of an FC could be invoked by a user equipment, i.e. the invoking entity of an FC could be allocated to user equipment. When an FC affects the user-network interface a service description is needed. Figure 8/I.310 illustrates FCs affecting different interfaces, FC1 affecting the user-network interface, FC2 affecting an internal network interface. It also illustrates that the invoking and responding entities of different FCs may appear in the same functional entity.
Figure 8/I.310, (N), p.
FCs are building blocks, which by themselves are not sufficient to provide a service. There is a need for some logic reflecting how FCs are coordinated in order to support a given service: this logic is termed service control process concept which can be found in other Recommendations.
Annex B gives descriptions of FCs so far identified for the ISDN.
Fascicle III.8 -- Rec. I.310 17
From the functional point of view, the process involved in satisfying a basic service request in the ISDN can be described as follows:
a) A basic service request contains a set of attribute values. The appropriate connection type(s) to support the service must be identified.
Service request examination:
|
-- -- -- b) |
input: service request containing a set of attribute values; process: examine service request and determine appropriate connection type(s); output: connection type(s). Once selected, the connection type (which has end-to-end significance) can be further broken down into one or more smaller |
functional components called ``connection elements'' (see Recommendation I.324).
|
A.1 |
Connection element selection: -- input: connection type; -- process: determine connection element(s) to form the connection type; -- output: connection element(s). c) Each connection element would require a set of functions in order to be established. Function set determination: -- input: connection element; -- process: select appropriate functions to establish connection element; -- output: set of functions. ANNEX A (to Recommendation I.310) List of identified basic elementary functions and additional elementary functions (EFs) for the ISDN |
A.1.1 BASIC EFs related to connection types
|
18 |
Connection handling BEF100 Characteristics of service requested examination BEF101 Connection elements type determination BEF102 User-network access resources reservation (channels) BEF103 Transit resources reservation BEF104 Communication references handling BEF 104 E: Establish call reference BEF 104 C: Clear call reference BEF105 Establishment control Fascicle III.8 -- Rec. I.310 |
|
BEF 105 R: BEF 105 F: BEF 150 B: BEF106 BEF107 BEF108 BEF109 BEF110 BEF111 BEF112 BEF113 BEF114 |
Establish connection-return path only Establish connection-forward path Establish connection-both directions Release control Service related authorizations examination User-network signalling handling (layer 3) Inter-exchange signalling handling (user part) Supplementary services compatibility checking Building up of and maintaining dynamic information relating to the call/connection Signalling interworking Priority Queue handling Fascicle |
III.8 -- Rec. I.310 19 |
|
Routing BEF200 BEF201 BEF202 BEF203 BEF204 BEF205 |
ISDN number identification Called number analysis (address analysis) Routing information examination (if provided) Predetermined specific routing Connection path selection Rerouting |
|
Resources handling BEF300 Hold and release of user-network access resources (channels) BEF 300 H: Hold user-network access resources BEF 300 R: Release user-network access resource BEF301 Hold and release of transit resources (circuits) BEF 301 H: Hold transit resources BEF 301 R: Release transit resources BEF302 Insertion and suppression of specific equipment BEF303 Tones, announcements and display information BEF304 User-network signalling handling (layer 1-2) BEF305 Inter-exchange signalling handling (message transfer) BEF306 Path search inside switching unit BEF307 Synchronization handling BEF308 Timing handling BEF309 Line service marking BEF310 Real time clock Supervision BEF400 User-network access resources monitoring BEF401 Transit resources monitoring BEF402 Continuity checking BEF403 Detection of congestion BEF404 Semi-permanent connection checking Operation and maintenance BEF500 Management of subscriber data BEF501 Fault report |
20 Fascicle III.8 -- Rec. I.310
|
Charging BEF600 BEF 600 I: BEF 600 C: BEF601 BEF602 BEF603 BEF604 BEF605 Interworking BEF700 |
Charging management Initiate charging Cease charging Charging registering Charging recording Billing Accounting Charging information Rate adaption |
||
|
BEF701 BEF702 BEF703 BEF704 BEF705 BEF706 BEF707 BEF708 |
Protocol conversion Handling of signalling for interworking Numbering interworking Special routing algorithms Negotiation Notification Charging for interworking Mapping of lower layer comparability |
Fascicle III.8 -- Rec. I.310 21 |
A.1.2 AEFs relating to supplementary services
|
AEF00 AEF01 AEF02 AEF03 AEF04 AEF05 AEF06 AEF07 AEF08 AEF09 AEF10 AEF11 AEF12 AEF13 AEF14 |
Insertion and suppression of additional resources (tones etc.) Line hunting Direct dialling-in Address determination Subscriber's dedicated storage Bridge User-network access resource hold Hold of communication Additional subscriber signalling Additional inter-exchange signalling Multi-call handling Internal call initialization Access/route restriction Subscriber call data registration Data display option |
A.2 Short description of elementary functions
A.2.1 Basic EFs related to connection types
A.2.1.1 Connection handling
100 Characteristics of service requested examination
Function of a functional entity to determine the required service characteristics (certain attributes of the bearer service and optional supplementary services) of a call by means of examination of information set by calling terminal.
|
101 |
Connection elements type determination Function of a functional entity to determine connection types and connection elements necessary to provide the requested service. |
|
|
102 |
User access resources reservation Function of a functional entity to determine the type of user-network access (basic, primary), the state of the resources (channels |
availability) and to reserve the channel(s) needed for establishing the access connection element.
103 Transit resources reservation
22 Fascicle III.8 -- Rec. I.310
Function of a functional entity to reserve the transit connection element, based on the state of resources.
104 Communication references handling
Function of a functional entity to assign a local reference (at the access interface) to the call and an internal reference (at the internal interface) to the connection, and to clear these references when the call/connection is cleared/released.
104 E Establish call reference. (For further study.)
|
104 C Clear call reference. (For further study.) |
|||
|
105 |
Establishment control Function of a functional entity to set up a connection through the functional entity. 105 R Establish connection-return path only. (For further study.) 105 F Establish connection-forward path. (For further study.) 105 B Establish connection-both direction. (For further study.) |
Fascicle III.8 -- Rec. I.310 23 |
|
106 |
Release control Function of a functional entity to release a connection through the functional entity. |
|
|
107 |
Service related authorization examination Function of a functional entity to determine the authorization (calling or called user) relating to basic and supplementary services that have |
been subscribed to.
|
108 |
User-network signalling handling (layer 3) Function of a functional entity to support the layer 3 protocol of the user-network signalling system. Note -- For layers 1 and 2, see § A.2.1.3, Resources handling. |
||
|
109 |
Inter-exchange signalling handling (user part) Function of a functional entity to support the user part of the inter-exchange signalling system. |
||
|
110 |
Supplementary services compatibility checking Function of the network to check the compatibility of requested supplementary services, e.g.: -- with requested bearer service to teleservice; -- with other requested supplementary services; |
and to verify coherence between parameters that may be associated.
|
111 |
Building-up of and maintaining dynamic information related to the call/connection Function of a functional entity to compile information related to the call/connection, e.g.: -- resources needed (connection type, connection elements, channels, circuits); -- details of call in progress; -- supplementary services effected and associated parameters. |
||
|
112 |
Signalling interworking Function of a functional entity to support interworking functions between signalling systems. |
||
|
113 |
Priority Function of a functional entity to handle specific calls with priority (e.g. in the case of overload or degraded mode of operation). |
||
|
114 |
Queue handling Function of a functional entity to store requests in a queue, in order to handle this information later in a predefined order. |
||
|
24 |
Fascicle III.8 -- Rec. I.310 |
A.2.1.2 Routing
200 ISDN number identification
Function of a functional entity to identify the ISDN number of the user-network interface. This information is limited to that included within the ISDN numbering plan.
201 Called number analysis
Function of a functional entity to analyse called ISDN number sent by the calling terminal in the call set-up phase.
Fascicle III.8 -- Rec. I.310 25
|
202 |
Routing information examination Function of a functional entity to analyse routing information that may be sent by the calling terminal and that has an effect on path selection. |
|
|
203 |
Predetermined specific routing Function of an exchange to select a specific routing according to the information received from the calling terminal (for example routing |
towards operators, access points, an interworking unit, an operational or maintenance unit, etc.).
204 Connection path selection
Function of a functional entity to select the transit outgoing part relating to connection types to be used, and the overall path through the network.
205 Rerouting
Function of a functional entity to select a new connection path through the network depending on changed conditions during call set-up or information transfer phases.
A.2.1.3 Resources handling
300 Hold and release of user-network access resources (channels)
Function of a functional entity to hold the access channel(s) reserved to support the communication, and to release it at the end of this communication.
300 H Hold user-network access resource. (For further study.)
300 R Release user-network access resource. (For further study.)
301 Hold and release of transit resources (circuits)
Function of a functional entity to hold the circuit(s) reserved to support the communication at the transit connection element and to release it at the end of this communication.
301 H Hold transit resources. (For further study.)
301 R Release transit resources. (For further study.)
302 Insertion and suppresion of specific equipment
Function of a functional entity to insert or remove specific equipments particularly to satisfy the service request invoked by the user. Examples of such equipment include:
|
26 |
-- echo -- A- -- interworking -- storage Fascicle |
echo suppressers; A-m law conversion units (change of A/D conversion); interworking unit; storage unit. III.8 -- Rec. I.310 |
|
303 |
Tones, announcements and display information Function of a functional entity to provide call progress information in one or more of the following ways: -- a tone is an audible (call progress) indication comprising one or more discrete frequencies but excluding |
speech; |
|
|
-- a recorded announcement is an audible indication in the form of speech or music; -- display information is (call progress) information set to the user which is displayed visually. Definitions of the other topics are not yet available. Fascicle |
III.8 -- Rec. I.310 27 |
|
304 |
User-network signalling handling (layers 1-2) Functions 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. In addition, it contains the binary information (i.e. subscribed to or not) for a range of supplementary services which the subscriber can use. In general this data does not contain information on the type of subscriber terminal, but it may contain information on the type of access (basic, primary rate, etc.), the type of NT2 (simple, intelligent, etc.) and the attributes of the services subscribed to.
310 Real time clock
Function of a functional entity to provide real time information.
A.2.1.4 Supervision
|
400 |
User-network Function |
User-network access resources monitoring Function of a functional entity to check the correct operation of subscriber access resources. |
|
|
401 |
Transit Function |
Transit resources monitoring Function of a functional entity to check the correct operation of the transit resources. |
|
|
402 28 |
Continuity Fascicle |
Continuity checking III.8 -- Rec. I.310 |
Function of a functional entity to control the checking operations relating to the continuity of a connection.
403 Detection of congestion
Function of a functional entity to detect congestion during the selection of a connection path.
Fascicle III.8 -- Rec. I.310 29
404 Semi-permanent connection checking
Function of a functional entity to check the availability of a given semi-permanent connection (e.g. passive continuity checking).
A.2.1.5 Operation and maintenance
|
500 |
Management of subscriber data Function of a functional entity to manage subscriber data related to services. Examples include: -- in/out of service -- number translation -- changing of subscriber data. |
||
|
501 |
Fault report Function of a functional entity to register the cause if an attempt to set up a call fails. |
A.2.1.6 Charging | (the groupings below require further study)
Function of the network to determine, collect and store the charging information. The following features are involved in this process:
600 Charging management
Function of a functional entity to determine by means of certain parameters the charging mode (free of charge, ordinary, peak, reduced rate charge, etc.). These parameters include service type, class of customer, time information, distance, etc.
600 I Initiate charging. (For further study.)
|
600 C Cease charging. (For further study.) |
||
|
601 |
Charging registering Function of a functional entity to register the details of the call (both short- and long-term storage). |
|
|
602 |
Charging recording Function of a functional entity to format the charging details in a standardized way. |
|
|
603 |
Billing Function of functional entity to calculate the variable charges to the customer which depend on the use of a service and on the fixed costs |
of the subscription. Both of these are accumulated over a fixed period of time. This billing is associated with the subscriber and not with a user-network interface, a terminal, etc.
604 Accounting
30 Fascicle III.8 -- Rec. I.310
Function of a functional entity to analyse, store and forward information relating to the use of inter-network resources between the different Administrations involved in a call.
605 Charging information
Function of the network to indicate the user the amount of the charge involved in the (current) use of the service.
Fascicle III.8 -- Rec. I.310 31
A.2.1.7 Interworking
Functions that permit the establishment of end-to-end connections when an ISDN and a dedicated network are involved. This requires the provision of the basic elementary features (BEFs) which are described below and others that have been defined already (service request examination, signalling interworking, called number analysis, routing information examination, insertion and suppresion of interworking units, etc.).
|
700 |
Rate adaption Function of a functional entity to adapt, according to a certain method, the user/dedicated network bit rates to the ISDN bit rates. |
||
|
701 |
Protocol conversion Function of a functional entity to support mapping functions between interfaces. |
||
|
702 |
Handling of signalling for interworking Function of a functional entity to handle signalling information for interworking (interpretation, termination, generation). |
||
|
703 |
Numbering interworking Function of a functional entity to support interworking functions between numbering plans. |
||
|
704 705 706 707 708 |
Special routing algorithms | (For further study) Negotiation | (For further study) Notification | (For further study) Charging for interworking | (For further study) Mapping of lower layer comparability (LLC) lists | (For further study) |
A.2.2 Additional EFs relating to supplementary services
AEF00 Insertion and suppression of additional resources (tone, etc.)
Note -- A definition has already been proposed for a basic EF. It needs to be considered if this feature should also be regarded as an additional feature. With respect to supplementary services a proposed description is:
Function of an exchange to manage (reserve, insert, release) additional resources related to the handling of supplementary services.
AEF01 Line hunting
32 Fascicle III.8 -- Rec. I.310
Function of a functional entity to select, on receipt of a certain terminal address, one free line in a multi-line group corresponding to that number.
AEF02 Direction dialling-in
Function of a functional entity to transfer address and other appropriate call handling information to a PABX for the purpose of setting up a call to its extensions without assistance of the PABX operator.
AEF03 Address determination
Function of a functional entity to determine the destination number(s) called by means of short-long number conversion or of association between one code and one list of numbers.
Fascicle III.8 -- Rec. I.310 33
AEF04 Subscriber's dedicated storage
Function of a functional entity to store details in addition to the LSM (line service marking) for each customer and which contains the registration data for supplementary services that have been subscribed to (i.e. listed in the LSM as binary 1). For example, it would contain a list of abbreviated numbers.
AEF05 Bridge
Functions of a functional entity to allow more than two individual participants on the same call.
AEF06 User-network access resource hold
Function of a functional entity to hold the user-network access resources (channel) involved in a communication in a waiting condition and, at the same time, to release the network connection. The call reference information is maintained.
AEF07 Hold of communication
Function of a functional entity to initiate the function to hold one, or more, of the other parties engaged in an established call in a waiting condition without the disestablishment of the call, and at the same time to release the initiating user-network access resource.
AEF08 Additional subcriber signalling
Functions of an exchange to send or receive specific signalling information to or from the user, related to the handling of supplementary services. (Additional signalling to the subscriber signalling for basic calls.)
AEF09 Additional inter-exchange signalling
Function of a functional entity to send or receive specific signalling information to or from another component, related to the handling of supplementary services. (Additional signalling to the inter-exchange signalling for basic calls.)
AEF10 Multi-call handling
Function of a functional entity to set up and manage several connections by means of a single procedure. (In response to only one call request.)
AEF11 Internal call initialization
Functions of a functional entity to initiate the setting-up of a connection without receiving a call request from the user [e.g. used for Completion of Call to Busy Subscribers (CCBS) supplementary service and alarm call services].
AEF12 Access/route restriction
|
Function of a functional entity to reject incoming or outgoing calls, either: -- totally for all services, or -- for one type of service (e.g. telephony). AEF13 Subscriber call data registration 34 Fascicle III.8 -- Rec. I.310 |
Function of a functional entity to register and display or print subscriber call data. Subscriber call data is information related to specific calls. This data is collected by the same functional entity as that which contains the EF ``subscriber call data registration''.
AEF14 Data display option
Functions of a terminal to display information to the user.
Fascicle III.8 -- Rec. I.310 35
ANNEX B
(to Recommendation I.310)
Descriptions of identified functional components (FCs) for
the ISDN
B.1 Hold invocation
This FC allows to invoke the disconnection of an established communication channel between the initiating and responding entities and its resevation for subsequent reuse for another (or the previous) communication. This implies the interruption of the communication for an existing connection.
|
The initiating entity provides the information required to identify the connection to be interrupted. The successful application of this FC results in: -- the disconnection of the communication channel between the initiating and the responding entities; -- the reservation of the disconnected communication channel for the initiating entity (for originating or terminating connections); -- an indication of successful completion from the responding entity. The unsuccessful application of this FC results in a response containing the failure details. Note -- The exact definition of communication channel is for further study. |
||
|
B.2 |
Retrieve This FC allows the initiating entity to request the reconnection of a communication channel between the initiating and responding entities in |
order to re-establish a previously held connection.
The initiating entity provides the information required to identify the connection to be re-established over the reserved communication channel.
The successful completion of this FC results in:
|
-- the re-establishment of the connection. The communication channel will be the exceptionally an alternate channel had to be allocated, the responding entity will indicate its identity; -- an indication of succesful completion from the responding entity. The unsuccessful application of the FC results in a response containing the failure details. |
reserved |
channel |
whenever |
possible. |
If |
The possible re-establishment of a connection over another communication channel than the reserved one is for further study.
B.3 Join
This FC allows to invoke the addition of a connection in order to form, or to add to, a multiparty connection of the same connection type.
The initiating entity provides all information required to identify the connection to be joined to the multi-party connection. The responding entity executes the functions to join the connection and provides the initiating entity with the information of the result of the execution.
Upon successful completion, all connections involved are connected together. A successful indication is returned to the initiating entity.
Upon unsuccessful completion, the status of last connection remains unchanged and an unsuccessful indication is returned to the initiating party with failure cause(s).
B.4 Split
This FC allows the initiating entity to separate a connection from a multiparty connection.
36 Fascicle III.8 -- Rec. I.310
The initiating entity provides the identities of the multiparty connection and the connection to be separated. The responding entity executes the functions to separate the designated connection from the multiparty connection.
Fascicle III.8 -- Rec. I.310 37
Upon successful completion the designated connection is separated from the multiparty connection. The separated connection is put on hold; the remainder of the multiparty connection remains unchanged. A successful indication is returned to the initiating entity.
Upon unsuccessful completion, the status of the multiparty connection remains unchanged and an unsuccessful indication is returned to the initiating party with failure cause(s).
|
B.5 |
Transfer This FC allows the initiating entity to reassign the ownership of a call to an elected subscriber. The initiating entity provides the identity of the connection to be transferred and the identity of the elected subscriber. Successful completion of this FC results in: -- the elected subscriber assumes the subsequent charges; -- the initiating entity receives a successful confirmation from the responding entity; -- the initiating entity is disconnected from the transferred connection. Upon unsuccessful completion, the status of the connection remains unchanged and an unsuccessful indication is returned to the initiating |
party with failure cause(s).
Note -- The concept of ownership requires further investigation in relation to control and charging aspects.
B.6 Notify
This FC provides the capability for one entity to inform another entity of some action or condition without requiring a response from the receiving entity.
|
Note -- A more precise definition of this FC is required. |
||
|
B.7 |
Enquire This FC provides the capability for the initiating entity to request information from another entity, without changing that information. The initiating entity provides to the responding entity what information is requested and other information the responding entity needs to |
respond successfully. For example, in requesting information from the responding entity about busy/idle status of an interface, the initiating entity provides information uniquely identifying that interface.
|
Upon successful completion, the responding entity returns to the initiating entity the requested information. Upon unsuccessful completion, the responding entity returns an unsuccessful indication including failure cause(s). |
||
|
B.8 |
Adjourn This FC provides the capability for the initiating and responding entities to retain knowledge of a call ( or call attempt) sufficient for |
subsequent re-establishment.
The initiating entity provides to the responding entity the identity of the call to be adjourned.
Upon successful completion, all channels previously allocated for the call (or call attempt) are released and the knowledge of the call is retained.
Upon unsuccessful completion, the status of the call remains unchanged and an unsuccessful completion indication with failure cause(s) is returned to the initiating entity.
B.9 Restart
38 Fascicle III.8 -- Rec. I.310
This FC provides the capability for the initiating entity to allocate resources to restore an adjourned call.
The initiating entity provides the identity of the adjourned call to be restored.
Upon successful completion, the necessary resources to re-establish the call are restored and the call set-up process resumes.
Upon unsuccessful completion, the adjourned call is released and a failure indication returned to the initiating entity including failure cause(s).
Fascicle III.8 -- Rec. I.310 39
B.10 Monitor
This FC allows the initiating entity to watch for an event (e.g. transition to idle, transition to busy) on a resource. The resource being monitored may be a network resource or a user resource.
The initiating entity provides the identity of the resource to be monitored, the event to be reported, and optionally the period of the monitor function. If the event to be monitored is the availability of a resource, the initiating entity may also request the resource be reserved when it becomes available. The responding entity will indicate acceptance or rejection of the monitor request immediately and subsequently check the states of the resource during the period specified.
|
Upon successful completion, the responding entity will notify the intiating entity if the period expired before the monitored event occured. Upon unsuccessful completion, an unsuccessful indication is returned to the initiating entity with failure cause(s). |
||
|
B.11 |
Reroute The FC allows the initiating entity to redirect an incoming call to an alternate address before the call is established. The initiating entity provides the identity of the incoming call and the aternate address to where the incoming call is to be redirected. Upon successful completion, the incoming call is connected to the alternate address. Upon unsuccessful completion, the responding entity provides to the initiating entity the cause of failure and the call processing of the |
incoming call is resumed.
BLANC
40 Fascicle III.8 -- Rec. I.310
SECTION 2
REFERENCE MODELS
ISDN PROTOCOL REFERENCE MODEL
(Malaga-Torremolinos, 1984; amended at Melbourne, 1988)
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 services introduced |
in |
|
Recommendations I.211 and I.212, by providing ISDN capabilities as defined in Recommendation 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.
Fascicle III.8 -- Rec. I.320 41
2.1 Relationship with the X.200-Series
The ISDN Protocol Reference Model (ISDN PRM) and the Open Systems Interconnection Reference Model (OSI RM) for CCITT Applications, 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 incorporates 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 type of the OSI PRM is tied to data communications and so, in this respect, its scope is more specific than the ISDN PRM. The OSI is used to model data communications between open systems in an ISDN environment.
The relative scopes of the two models are illustrated by Figure 1/I.320. The existence of a common intersection shows that these models coexist and overlap.
Figure 1/I.320, (N), p.
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 (Recommendation X.200), and the notions of service primitive, peer entity and peer protocol (Recommendation 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 numbers. 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.
Note that the term ``network'' in the ISDN corresponds to ``sub-network'' in the OSI terminology.
42 Fascicle III.8 -- Rec. I.320
|
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 multiple 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 functions (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: i) voice (including A/m law conversion), ii) full motion video, iii) transparent flow, IV telex. |
||
|
2.2 |
Control and user planes The support of out-of-band signalling and 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 transparently through an ISDN, or it may be processed or manipulated, e.g. A/m law 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 controls the exchange of data within a connection, but otherwise does not alter the state of this connection (e.g. flow control), pertains to the U-plane. All control information which involves resource allocation/deallocation by the ISDN pertains to the C-plane.
2.3 Local and global significance
Fascicle III.8 -- Rec. I.320 43
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).
44 Fascicle III.8 -- Rec. I.320
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
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 global significance;
-- the control of any resources to be used at the user-network interface has local significance;
and, 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. |
Figure 2/I.320, (N), p. |
Depending on their functional requirements, supplementary services relate to either the local, or global perspective. For example:
-- completion of calls to busy subscribers (CCBS) or user-to-user signalling (UUS) 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 |
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). |
The ISDN PRM is represented by a protocol block which incorporates the concepts of layer, significance and plane described above.
Such a protocol block can be used to describe various elements in the ISDN user premises and the network [e.g. terminal equipment (TE), ISPBX network termination (NT), exchange termination (ET), signalling point (SP) and signalling transfer point (STP), etc.].
Fascicle III.8 -- Rec. I.320 45
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 (LC) plane, and a global control (GC) plane, in addition to the user (U) plane.
The layering principles apply in each of these planes: each plane can potentially accommodate a 7-layer stack of protocols. A plane management function is required to allow coordination between the activities in the different planes. Examples of plane 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 in Figure 3/I.320.
Note -- The plane management function should not be confused with the system management as introduced to model OSI management.
The following remarks apply:
|
1) the LC-plane the OSI RM. 2) |
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 requirements; however, entities communicating in this plane are application layer entities. Note that this is not in contradiction with 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) 4) study. |
A network element -- unless it provides a high layer function (HLF) -- will generally not support any U-plane protocol above layer 3. The need for application processes specific to each plane, or for application processes able to access several planes, is for further |
|
|
Figure 3/I.320, (N), p. |
46 Fascicle III.8 -- Rec. I.320
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 telecommunication 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:
|
-- D-channel; -- |
control and user information may use the same support, e.g. when in-band signalling is used, or when user information is carried on a LC and GC information 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.
For further study.
|
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. 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 -- a service which is required to support the telecommunication service to be provided, which is |
to provide (F is then empty); offered by both networks, but by |
means of different capabilities in the two networks.
Fascicle III.8 -- Rec. I.320 47
|
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. |
|
|
48 |
Fascicle III.8 -- Rec. I.320 |
Figure 4/I.320, (N), p. 13
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 service S; this will result in different (and independent) requirements on the LC-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 phase.
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.
Fascicle III.8 -- Rec. I.320 49
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 as 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 C-plane with LC 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 access point to the OSI system.
|
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. |
||
|
50 |
Fascicle III.8 -- Rec. I.320 |
|
Figure 5/I.320, (N), p. 14 Figure 6/I.320, (N), p. 15 |
6.2 More elaborate situations
|
-- -- -- -- -- |
supplementary services: completion of calls to busy subsribers (CCBS); three-party service; PABX facilities; OAM (operational, administrative and maintenance) applications. |
Fascicle III.8 -- Rec. I.320 51 |
|
6.3 |
Interworking -- at -- with -- with -- inside -- of |
Interworking at reference point R (Teletex terminal): with a PSTN; with a PSPDN (Videotex); inside an ISDN (provision of an HLF by the network); of public ISDN with other networks (a possible example is given in Figure 7/I.320). |
|||
|
Figure 7/I.320, (N), p. |
|||||
|
52 |
Fascicle |
III.8 -- Rec. I.324 |
MONTAGE: Rec. I.324 sur le reste de cette page
Fascicle III.8 -- Rec. I.324 53
54 Fascicle III.8 -- Rec. I.324