delim @@
| 5i'
FRAMEWORK FOR PROVIDING ADDITIONAL PACKET MODE BEARER SERVICES
(Melbourne, 1988)
Packet mode bearer services supported by an ISDN are given in Recommendation I.232. Recommendation I.462 (X.31) specifies the procedures for two such bearer services, virtual call and permanent virtual circuit bearer services, for the support of X.25 packet mode terminals in ISDN.
This Recommendation establishes an architectural framework within which additional packet mode bearer services are described.
1.1 Scope
The architectural framework and service descriptions given in this Recommendation provide the basis for further work to be done by CCITT during the 1989-1992 Study Period. This method of work involves first the description of services and then the development of protocols to support them.
During the course of this work the first ISDN principle given in Recommendation I.120 should be followed. That is, a wide range of applications should be supported by the same network using a limited set of connection types and multipurpose user-network interface arrangements. From considerations in this Recommendation it is also desirable to limit the number of bearer services. It is recognized, however, that at this time it is premature to exclude any potential bearer services. The criteria on the basis of which the number of these bearer services could be reduced requires further study.
The Recommendation also provides a general description on interworking requirements between I.122 based services and I.462 (X.31) based services or PSPDNs.
1.2 Objectives
The principle of separation of the user and control planes for all telecommunication services has been established as a fundamental concept of the ISDN protocol reference model (Rec. I.320). This principle has been applied, however, only to circuit mode services. Packet mode services in ISDN are based on Recommendation I.462 (X.31). Recommendation I.462 (X.31) is a pragmatic approach that minimizes deployment and interworking difficulties, while at the same time providing access to packet services through an integrated physical interface.
The evolution of packet mode services in ISDN has been investigated, and an architectural framework for providing additional packet mode services has been established in this Recommendation. In undertaking this investigation the main objective was to establish a framework based on the ISDN protocol reference models described in Recommendation I.320. More specifically, this framework was aimed at achieving:
a) full integration of C-plane (control plane) procedures for all services, i.e. one set of protocols for call control; supplementary services and operational, administrative and maintenance messages (OAM) across all
Fascicle III.7 -- Rec. I.122 1
telecommunication services;
b) the decoupling of user information transfer requirements from C-plane transfer requirements. This allows the possibility of defining telecommunication services whose U-plane (user plane) characteristics are tailor-made only to the transfer needs of user information and not to those of C-plane information.
The bearer services supported within this architectural framework are in the virtual call and permanent virtual circuit bearer service category. All bearer services defined within this framework if and when included in Rec. I.232 will have recommended overall provision A (Additional).
2 Fascicle III.7 -- Rec. I.122
1.3 Definitions of terms
In the context of this Recommendation, the following definitions apply:
Note -- This list is not complete. For example, some of these definitions apply to terms relevant to only some of the bearer services discussed in this Recommendation.
1.3.1 delivered duplicate frames
A frame D received by a particular destination user is defined to be a duplicated frame if both of the following conditions are true:
a) D was not generated by the source user;
b) D is exactly the same as a frame that was previously delivered to that destination.
1.3.2 delivered errored frames
A delivered frame is defined to be an errored frame when the value of one or more bits in the frame is in error, or when some, but not all, bits in the frame are lost bits or extra bits (i.e. bits that were not present in the original signal). (See Rec. X.140).
1.3.3 delivered out-of-sequence frames
Consider a sequence of frames F1, F2, f3, | | | , Fn. Assume that F1is transmitted first, F2second,
| | | Fnlast.
A delivered frame Fiis defined to be out-of-sequence if it arrives at the destination user after any of the frames F (i + 1) , F (i + 2) , | | | , Fn.
1.3.4 dynamic window control
The term dynamic window control refers to a set of procedures based on which the transmitter's transmit window is modified, according to a user-perceived congestion condition in the network.
1.3.5 end-to-end communication
End-to-end communication is a direct peer-to-peer communication of TE to TE, or TE to a network interworking function (IWF) supporting, for example, PSPDN interworking.
1.3.6 explicit congestion message
Explicit congestion message is a message generated by the network and sent to a user terminal to indicate a congestion condition.
1.3.7 implicit congestion control
Implicit congestion control is a scheme under which user terminals first detct a possible congestion condition by means other than explicit congestion messages, and then take appropriate action to reduce their throughput.
Fascicle III.7 -- Rec. I.122 3
1.3.8 information integrity
Information integrity is a network providing frame-relaying bearer service defines that all frames carried by the network shall satisfy the FCS check.
1.3.9 logically separate (C-plane information)
Logically separate means that C-plane information is sent separately from U-plane information in one of the following ways:
1) on a physically separate interface;
2) on another channel (time slot) within the same interface; or
3) on a separate logical link within the same channel (e.g., D-channel).
4 Fascicle III.7 -- Rec. I.122
1.3.10 lost frames
A transmitted frame is declared to be a lost frame when the frame is not delivered to the intended destination user within a specified timeout period, and the network is responsible. (See Rec. X.140).
1.3.11 misdelivered frames
A misdelivered frame is a frame transferred from a source user to a destination user other than the intended destination user. It is considered inconsequential whether the information is correct or incorrect in content. (See Rec. X.140).
1.3.12 quality of service (QOS)-parameter set (See Rec. X.213)
For each QOS-parameter, a set of ``subparameters'' is defined from among the following possibilities:
a) a target | value which is the QOS value desired by the calling user;
b) the lower quality acceptable | value which is the lowest QOS value agreeable to the calling user. (When the lowest quality acceptable refers to throughput, the term ``minimum'' may be used, while when it refers to transit delay, the term ``maximum'' may be used.);
c) an available | value which is the QOS that the network is willing to provide;
d) a selected | value which is the QOS value to which the called user agrees.
1.3.13 real time call establishment
The term real time call establishment refers to a set of procedures based on which the communication can be started in a relatively short time (i.e. in the order of a few seconds) after the request is made. (See definition for demand communication establishment in Rec. I.130).
1.3.14 residual error rate
Residual error rate is defined for both the additional packet-mode bearer services and the corresponding layer services.
The layer services corresponding to the additional packet-mode bearer services are characterized by the exchange of service data units (SDUs). For frame relaying 1, SDUs are exchanged at the functional boundary between the core functions of Recommendation and the end-to-end protocol implemented above them. For frame relaying 2 and frame switching, SDUs are exchanged at the functional boundary between the complete I.441* and the end-to-end functions implemented above I.441*. For the X.25-based additional packet mode service (APMS), SDUs are exchanged at the functional boundary of X.25 PLP-DTP (packet layer protocol-data transfer part) and the end-to-end functions implemented above.
The network participates in this exchange by means of protocol data units (PDUs). In frame relaying 1 and 2, PDUs are frames as defined in the core functions of I.441*. In frame switching, PDUs are frames as defined in I.441*, while in X.25-based APMS, they are packets as defined in X.25 PLP.
The residual error rate for the corresponding layer service of APMS is defined as:
R = 1 --
@ { otal~correct~SDUs~delivered } over { otal~offered~SDUs } @
I.441* is I.441 with appropriate extensions. The use of the extensions may depend on each bearer service
and is for further study.
Fascicle III.7 -- Rec. I.122 5
The residual error rate for the APMS is defined as the ratio:
|
R = 1 -- |
6 Fascicle III.7 -- Rec. I.122
1.3.15 throughput
Throughput for a virtual connection section in a network providing the frame relaying bearer service, is the number of data bits contained between the address field and the FCS field of the frames successfully transferred in one direction across that section per unit time. Successful transfer means that the FCS check for each frame is satisfied.
1.3.16 transit delay
Transit delay is defined only between pairs of section boundaries starts at the time t1at which the first bit of the FPDU crosses the first boundary, and ends at the time t2at which the last bit of the FPDU crosses the second boundary.
Transit delay = t2--t1.
2.1 General service characteristics
This Recommendation describes a set of potential packet mode bearer services that have the following characteristics in common:
1) All C-plane procedures, if needed, are performed in a logically separate manner using protocol procedures that are integrated across all telecommunications services (i.e. I.451 with appropriate extensions).
2) The U-plane procedures share the same layer 1 functions based on Rec. I.430/I.431. Moreover, they share the same core procedres, defined in § 3.1, that among other functions allow for statistical multiplexing of user information flows immediately above the layer 1 functions.
The basic bearer service provided by the network is the order preserving bidirectional transfer (see § 2.3.1) of service data units (i.e. frames or packets) from one S/T reference point to another. The data units are routed through the network on the basis of an attached label (e.g. the data link connection identifier (DLCI) value of the frame). This
label is a logical identifier with local significance. In the virtual call case, the value of the logical identifier and the other associated parameters are negotiated during the call set-up by means of C-plane procedures. Depending on the bearer service and parameters, the network may accept or reject the user requested service. In the permanent virtual circuit case, the logical identifier and the other associated parameters are defined by means of administrative procedures. The network treatment of the data units, (e.g. unacknowledged transfer, acknowledged transfer, error recovery) in addition to simple transfer, depends on the specific bearer service requested.
The user network interface structure at the S/T reference point allows for the establishment of multiple virtual calls and/or permanent virtual circuits to many destinations.
2.2 Quality of Service parameters
Each potential bearer service described in this Recommendation provides service quality that is characterized by the values of the following parameters:
1) throughput;
2) transit delay;
Virtual connection section is defined in Rec. X.134.
The definition of section boundaries is given in Rec. X.134.
The definition of FPDU is given above in residual error rate.
Fascicle III.7 -- Rec. I.122 7
|
8 |
3) information 4) residual 5) delivered 6) delivered 7) delivered Fascicle |
information integrity; residual error rate; delivered errored frames; delivered duplicated frames; delivered out-of-sequence frames; III.7 -- Rec. I.122 |
8) lost frames;
9) misdelivered frames;
|
10) others for further study. Note -- The applicability and values of these parameters for different bearer services are for further study. |
||
|
2.3 |
Individual bearer service descriptions This section contains descriptions of four specific potential bearer services proposed for standardization: a) frame relaying 1, b) frame relaying 2, c) frame switching, and d) X.25-based additional packet mode. |
|
|
2.3.1 |
Frame relaying 1 service description Frame relaying 1 shares with the other services the general service characteristics and quality of service |
parameters described in §§ 2.1 and 2.2, respectively.
The frame relaying 1 data units are frames as defined in Rec. I.441. The basic bearer service provided is the unacknowledged transfer of frames from S/T to S/T reference point. More specifically, in the U-plane:
1) it preserves their order as given at one S/T reference point if and when they are delivered at the other end.
Note -- Since the network does not terminate the upper part of I.441, sequence numbers are not kept by the network. Networks should be implemented in a way that, in principle, frame order is preserved;
2) it detects transmission, format and operational errors (e.g. frames of unknown DLCI);
3) frames are transported transparently (in the network), only the address and FCS field may be modified;
4) it does not acknowledge frames (within the network).
All of the above functions are based on Rec. I.441. Appropriate extensions to the core functions of Rec. I.441 may be needed, e.g. for congestion control. In the C-plane all signalling capabilities for call control, parameter negotiation, etc. are based on a common set of protocols (e.g. Rec. I.451 extended), as for all ISDN telecommunication services. In the case of permanent virtual circuits (PVC) no real time call establishment is necessary and parameters are agreed upon at subscription time.
However, additional functions are needed:
-- to monitor throughput and to enforce it,
-- to control congestion.
The mechanisms to achieve these functions are still under investigation.
Appropriate protocol capabilities should be available so that the network may discard erroneous frames if it elects to do so. Note that if networks elect to forward erroneous frames to the user, fraud and misdelivery of frames may occur.
From the service perspective, frame relaying 1 provides service quality characteristics with the following parameter values:
(Parameter values are for further study).
Fascicle III.7 -- Rec. I.122 9
2.3.2 Frame relaying 2 service description
Frame relaying 2 shares with the other services the general service characteristics and Quality of Service parameters described in §§ 2.1 and 2.2, respectively.
10 Fascicle III.7 -- Rec. I.122
The frame relaying data units are frames as defined in Rec. I.441. The basic bearer service provided is an unacknowledged transfer of frames from S/T to S/T reference point. More specifically, in the U-plane:
1) it preserves their order as given at one S/T reference point if and when they are delivered at the other end.
Note -- Since the network does not terminate th upper part of I.441, sequence numbers are not kept by the network. Networks should be implemented in a way that, in principle, frame order is preserved;
|
2) 3) 4) 5) |
it detects transmission, format and operational errors (e.g. frames of unknown DLCI); frames are transported transparently in the network, only the address and FCS field may be modified; it does not acknowledge frames (within the network); normally the only frames received by a user are those sent by the distant user. (Currently, implicit |
congestion control is preferred in which the network does not generate any congestion control messages toward the user. The generation of explicit congestion control messages by the network is for further study.)
All of the above functions are based on Rec. I.441. Appropriate extensions to Rec. I.441 may be needed, e.g. in relation to congestion control.
In the C-plane all signalling capabilities for call control, parameter negotiation, etc. are based on a common set of protocols (e.g. Rec. I.451 extended), as for all ISDN telecommunication services. In the case of permanent virtual circuits (PVC) no real time call establishment is necessary and any parameters are agreed upon at subscription time.
However, additional network functions are needed:
-- to monitor throughput and to enforce it,
-- to control congestion.
The mechanisms to achieve these functions are still under investigation.
Appropriate protocol capabilities should be available so that the network may discard erroneous frames if it elects to do so. Note that if networks elect to forward erroneous frames to the user, fraud and misdelivery of frames may occur.
The difference between the two types of frame relaying is that in frame relaying 2 the end points always implement, above the core functions, the upper part of Rec. I.441 extended. Consequently, in frame relaying 2 the network may take advantage of the knowledge of the layer 2 parameters in order to facilitate network operations such as charging and resource allocation. In frame relaying 1 the functions implemented end-to-end above the core functions are user selectable and may not be the upper part of Rec. I.441. Consequently, in frame relaying 1 the network in principle has no knowledge of the protocol used end-to-end.
From the service perspective, frame relaying 2 provides service quality characteristics with the following parameter values:
(Parameter values are for further study).
The terminal operates with an extended I.441 protocol. As a result the user perspective is the transparent transport of data end-to-end, with a quality influenced by the statistical multiplexing of data streams in the network. Acknowledgement of data is end-to-end as well as error detection and recovery.
2.3.3 Frame switching service description
Frame switching has general service characteristics and Quality of Service parameters as given in §§ 2.1 and 2.2, respectively.
In addition, in the U-plane, frame switching:
1) provides for the acknowledged transport of frames;
Fascicle III.7 -- Rec. I.122 11
|
2) 3) 4) All |
of |
detects and recovers from transmission, format, and operational error; detects and recovers from lost or duplicated frames; provides flow control. the above functions are based on Recommendation I.441. |
Appropriate extensions to |
Recommendation I.441 may be needed.
12 Fascicle III.7 -- Rec. I.122
In the C-plane all signalling capabilities for all call control, parameter negotiation, etc. are based on a common set of protocols (e.g. Rec. I.451 extended), as for all ISDN telecommunication services. In the case of permanent virtual circuits no real time call establishment is necessary and any parameters are agreed upon at subscription time.
From the service perspective, frame switching provides service quality characteristics with the following parameter values:
(Parameter values are for further study).
2.3.4 X.25-based additional packet mode service description
X.25-based additional packet mode has general service characteristics and Quality of Service parameters similar to the packet mode services described in X.31.
The U-plane capabilities are the same as in X.25 PLP Data Transfer Part (DTP)
In the C-plane all signalling capabilities for call control, parameter negotiation, etc. are based on a common set of protocols (e.g. Rec. I.451 extended), as for all ISDN telecommunication services. In the case of permanent virtual circuits (PVC) no real time call establishment is necessary and any parameters are agreed upon at subscription time.
Figure 1/I.122 is a direct application of the ISDN protocol reference model to the packet mode communications discussed in this Recommendation. It shows the user-network interface protocol architecture. Only those functions on the network side that are visible on the user side of the S/T reference point are shown.
On the user side, Recommendations I.430 or I.431 provide the layer 1 protocol for the U- (user) C- (control) planes. The C-plane uses the D-channel with Recommendations I.441 extended and I.451 extended as the layer 2 and 3 protocols, respectively. In the case of permanent virtual circuits (PVC) no real time call establishment is necessary and any parameters are agreed upon at subscription time. The U-plane may use any channel (D, B, H0and H1) on which the user implements at least the lower part (the core functions) of Recommendation I.441.
Figure 1/I.122, p.
Fascicle III.7 -- Rec. I.122 13
H.T. [T1.122]
TABLE 1/I.122
U-plane functions applicable to each bearer service
|
center box; cw(96p) | cw(66p) | cw(66p) . Bearer service User terminal (Note 1) 1 I.441* Core (Note 2) I.441* Core _ lw(96p) | lw(66p) | lw(66p) . Frame relaying 2 Frame switching I.441* I.441* _ lw(96p) | lw(66p) | lw(66p) . { X.25-based additional packet mode } I.441* X.25 DTP I.441* X.25 DTP Note 1 -- Additional user selectable functions may be implemented. |
Network _ lw(96p) | lw(66p) | lw(66p) . Frame relaying I.441* I.441* Core _ lw(96p) | lw(66p) | lw(66p) . |
Note 2 -- I.441* is I.441 with appropriate extensions. The use of the extensions may depend on each bearer service and is for further study.
|
Table 1/I.122 [T1.122], p. |
||
|
3.1 |
Core functions of Rec. I.441 The core functions are: -- frame delimiting, alignment, and transparency, -- frame multiplexing/demultiplexing using the address field, -- inspection of the frame to ensure that it consists of an integer number of octets prior to zero bit insertion or following zero bit |
extraction,
-- inspection of the frame to ensure that it is neither too long nor too short (see Note),
|
-- detection of transmission errors. Note -- The maximum and minimum frame lengths that apply to the Additional packet mode bearer services are for further study. |
||
|
3.2 |
Other user terminal functions If not already prescribed by the selected packet mode bearer service, the user may also implement functions such as, for example, |
recovery from detected transmission, format, and operational errors above the core functions using the full procedures of Recommendation I.441. Additional functions such as flow control may also be implemented. For example, X.25 data transfer functions may also be implemented above the preceding stack.
3.3 Network functions
On the network side, Recommendations I.430 or I.431 provide the layer 1 protocol for both C- and U-planes. The C-plane is handled just as on the user side, i.e. the network fully terminates the protocols of Recommendations I.441 and I.451. In the U-plane, at least the core functions of Recommendation I.441 protocol are terminated. The network may terminate additional protocol functions only as requested by the user and negotiated and agreed to by the user and the network. The U-plane protocols to be terminated by the network are determined by the specific bearer service requested by the user, and negotiated and agreed to by the user and network.
Interactions between the U- and C-planes of the terminal, and between the U- and C-planes of the network are independent. As a result, coordination between the U- and C-planes at the users equipment is not the responsibility of the network.
14 Fascicle III.7 -- Rec. I.122
During the three phases of a call (call establishment, data transfer, and call clearing), C- and U-plane synchronization is achieved in a similar way as for all ISDN telecommunications services. That is, after the C-plane has established the connection, the U-plane may commence data transfer with or
without an initialization procedure in the U-plane. In the case of permanent virtual circuit the establishment and call clearing is accomplished by administrative procedures.
3.4 Further service requirements at the user-network interface
Procedures at the user-network interface should be also applicable when two users are connected via a circuit mode bearer service (permanent or demand). Mechanisms that can be used to achieve this objective include, for example, the symmetrization of the procedure involved, or the use of additional procedures for the determination of the asymmetric relationships. The selection of such a mechanism is for further study.
3.5 Potential bearer services
Four potential bearer services are identified as part of this architectural framework. The first potential bearer service, frame relaying 1, is provided when no functions above the core functions are terminated by the network: if needed, such functions are terminated only end-to-end.
The second potential bearer service, frame relaying 2, is provided when no functions above the core functions are terminated by the network; I.441 upper functions are terminated only at the end points.
The third potential bearer service, frame switching, is provided when the full Recommendation I.441 protocol is terminated by the network.
The fourth potential bearer service, X.25-based additional packet mode, is provided when the full Recommendation I.441 protocol and the data transfer part (DTP) of Recommendation X.25 PLP (packet layer protocol) are terminated by the network.
Further information on the service characteristics of these four potential bearer services is given in Annex A.
4.1 Interworking between packet mode services
To interconnect different packet mode bearer services, it is necessary to provide interworking between an ISDN offering any of the bearer services described in this Recommendation, and:
1) an ISDN offering any of these additional packet mode bearer services,
2) an X.25-based service offered either by an ISDN or a PSPDN.
For interworking configuration 1), procedures for both the C-plane and the U-plane at an internetwork reference point which includes international gateway reference points, have to be standardized. In addition it would be desirable that these procedures be developed in such a way that they also could be used at an inter-exchange reference point within an ISDN offering any of the bearer services described in this Recommendation. Examples of such procedures may include: routing, address translation, security and accounting tasks.
For interworking configuration 2), interworking based on either call control mapping or port access is possible. A high level description of interworking arrangements is contained in Annex B.
4.2 Support of existing terminals
Additionally, terminal adapter functions should be provided that allow existing terminals (e.g. asynchronous, start/stop DTEs, X.25 packet mode DTEs and V-Series interface terminals) to access from an ISDN one or more of the bearer services described in this Recommendation.
4.3 Interworking with circuit mode services
Fascicle III.7 -- Rec. I.122 15
Other service interworking configurations (e.g. with a CSPDN, or between different bearer services within an ISDN) may also need to be considered.
16 Fascicle III.7 -- Rec. I.122
In the interworking between an ISDN offering any of the bearer services described in this Recommendation and X.25-based service offered either by an ISDN or a PSPDN, an interworking function (IWF) is required.
To support network layer service (Rec. X.213) when the bearer service used is one of the bearer services described in this Recommendation, the use of additional end system functionality may be required and end-to-end (i.e. TE-to-TE or TE-to-IWF) compatibility must be ensured.
Annex C contains requirements for the support of network layer service (Rec. X.213).
Packet mode bearer services described in this Recommendation aim at data services up to 2 Mbit/s. Within this broad category, some specific applications are as follows:
1) Block interactive data applications
An example of a block interactive application would be high resolution graphics (e.g. high resolution videotex, CAD/CAM). The main characteristics of this type of application are low delays [e.g. approximately less than . | | ms (the exact value is for further study)] and throughput approximately in the range of 500 kbit/s to 2048 kbit/s.
2) File transfer
The file transfer application is intended to cater for large file transfer requirements. Transit delay is not as critical for this application as it is for example in the first application. Higher throughput (e.g. 16 kbit/s to 2048 kbit/s) might be necessary in order to produce reasonable transfer times for large files.
3) Multiplexed low bit rate
The multiplexed low bit rate application exploits the multiplexing capabilities of the layer 2 protocol in order to provide an economical access arrangement for a large group of low bit rate applications. The low bit rate sources should be multiplexed onto any ISDN-channel by an NT function which could take the form of a LAN, PABX, or Centrex. The delay requirements are in the area of | | | ms (the exact value is for further study) and the throughput within the range of 16 kbit/s to 2048 kbit/s.
4) Character-interactive traffic
An example of a character-interactive traffic is text editing. The main characteristics of this type of applications are short frames, low delays and low throughput.
|
Identification of additional applications and their characteristics (e.g. delay, Recommendation are desirable for the complete definition of the service requirements. ANNEX A (to Recommendation I.122) |
throughput, etc.) |
for |
bearer |
services |
described |
in |
this |
Further service-related information
A.1 Introduction
This Annex contains further service related information on the I.122 based bearer services. The intent of this Annex is to clarify and supplement the service descriptions given in the main body of this Recommendation. Note that the information given in this Annex should not be interpreted as material that completes the service descriptions of the bearer services given in this Recommendation.
Fascicle III.7 -- Rec. I.122 17
|
A.2 A.2.1 |
Service related information Frame relaying 1 The U-plane configuration for this service is shown in Figure A-1/I.122. Figure A-1/I.122, p. Figure A-1/I.122 shows the network in a generic way and illustrates all U-plane functions up to and including layer 3. In a specific network, |
|
|
frame |
relaying 1 may be implemented in one or more nodes, all other nodes in the network providing only circuit-mode functions. Frame relaying 1 can be offered on both, basic and primary rate interfaces and on any ISDN channel (D, B, and H). Some restrictions (e.g. |
|
|
frame |
length) apply when in an end-to-end connection at least one of the access channels is the D-channel (16 kbit/s). The bearer service provided by the network at the S/T reference point supports only the core functions defined in § 3.1. A frame received |
by such a point is discarded if the frame does not meet the I.441 core format requirements (for example, if the frame is too long, has an unknown label, etc.). Moreover, frames may be discarded due to internal network conditions, or other reasons such as throughput enforcement.
In all other cases, the frame is relayed to one of the adjacent nodes according to the routing plan established at call set-up time, or at subscription time (if the network is providing a permanent virtual circuit service).
No additional U-plane functions (see Note) visible to the users are performed by the network. If needed by the application, additional functions are performed end-to-end by layer(s) above the core functions.
Note -- Some additional auxiliary U-plane functions such as reset or explicit congestion control may be defined if needed from the service perspective.
18 Fascicle III.7 -- Rec. I.122
|
A.2.2 |
Frame relaying 2 The U-plane configuration for this service is shown in Figure A-2/I.122. Figure A-2/I.122, p. Figure A-2/I.122 shows the network in a generic way and illustrates all U-plane functions up to and including layer 3. In a specific network, |
|
|
frame |
relaying 2 may be implemented in one or more nodes, all other nodes in the network providing only circuit-mode functions. Frame relaying 2 can be offered on both, basic and primary rate interfaces and on any ISDN channel (D, B, and H). Some restrictions (e.g. |
|
|
frame |
length) apply when in an end-to-end connection at least one of the access channels is the D-channel (16 kbit/s). The bearer service provided by the network at the S/T reference point supports only the core functions defined in § 3.1. A frame received |
by such a point is discarded if the frame does not meet the I.441 core format requirements (for example, if the frame is too long, has an unknown label, etc.). Moreover, frames may be discarded due to internal network conditions, or other possible reasons such as throughput enforcement.
The terminals operate end-to-end with the complete I.441* protocol. In all other cases, the frame is relayed to one of the adjacent nodes according to the routing plan established at call set-up time, or at subscription time (if the network is providing a permanent virtual circuit service).
No additional U-plane functions (see Note) visible to the users are performed by the network. If needed by the application, additional functions are performed end-to-end by layer(s) above the core functions.
Note -- Some additional auxiliary U-plane functions such as reset or explicit congestion control may be defined if needed from the service perspective.
A.2.3 Frame switching
The U-plane configuration for this service is shown in Figure A-3/I.122.
Figure A-3/I.122 shows the network in a generic way and illustrates all functions up to and including layer 3. In a specific network, frame switching must be implemented in at least one node in the network.
Fascicle III.7 -- Rec. I.122 19
Figure A-3/I.122, p.
Frame switching can be offered on both basic and primary rate interfaces and on any ISDN channel (D, B, and H). Some restrictions (e.g.
frame length) apply when in an end-to-end connection at least one of the access channels is the D-channel (16 kbit/s).
The bearer service provided by the network at the S/T reference point supports the full Recommendation I.441 function. Received frames that satisfy the Recommendation I.441 procedure are passed on to an adjacent node according to a routine plan established at call set-up time, or at subscription time.
No additional U-plane functions visible to the users are performed in the network. If needed by the application, additional functions are performed end-to-end by layer(s) above layer 2.
A.2.4 X.25-based additional packet mode
The U-plane configuration can comprise several nodes having layer 1, layer 2, and layer 3 functions as is shown in Figure A-4/I.122. Figure A-4/I.122 shows the network in a generic way and illustrates all functions up to and including layer 3. Other configurations with nodes making use only of the core aspects of Recommendation I.441 as defined in § 3.1 of Recommendation I.122 are possible.
Figure A-4/I.122, p. 20 Fascicle III.7 -- Rec. I.122
X-25-based additional packet mode service can be offered on both the basic and primary rate ISDN access interfaces and on any ISDN channel (D, B, and H). Some restrictions (e.g. packet length) apply when in an end-to-end connection at least one of the access channels is the D-channel (16 kbit/s).
The bearer service provided by the network at the S/T reference point supports the full Recommendation I.441 and the data transfer part of Recommendation X.25 PLP functions.
The U-plane contains X.25-based layer 3 functions and the C-plane procedures use Recommendation I.451 extended to transfer the parameters necessary for the establishment and release of virtual circuits (e.g. throughput class, window size, etc.). The capability to negotiate some parameters must also be provided. Whether or not X.25 multiplexing is provided is for further study.
X.25 PLP-DTP consists of all X.25 PLP functions with the exception of the connection establishment and release functions, including user facilities (supplementary services). The exclusion of other X.25 PLP functions is for further study.
ANNEX B
(to Recommendation I.122)
General arrangement for interworking between an ISDN
where I.122 bearer services are requested
and an ISDN or a PSPDN providing service based on Recommendation X.25
B.1 Possible scenarios
Figure B-1/I.122 shows the interworking arrangements considered. When the interworking function IWF logically belongs to the ISDN (Recommendation I.122), interworking based on call control mapping takes place. In the case where the IWF logically belongs to the PSPDN (Recommendation X.25) or ISDN (Recommendation X.31), interworking based on either call control mapping or port access is possible. As shown in the figure, different interfaces can be specified for the different reference points, depending on whether the IWF logically belongs to the ISDN (Recommendation I.122), or to the PSPDN (Recommendation X.25) or ISDN (Recommendation X.31).
B.2 IWF logically belonging to ISDN (Recommendation I.122)
To enable interworking, the I.122 bearer services, in conjunction with an IWF, should provide full support of the X.213 network layer services. The association of an ISDN (Recommendation I.122) with an IWF in such a manner could therefore be considered globally as a Type I subnetwork, in the sense defined in Recommendation X.300.
|
A PSPDN (Recommendation X.25) or an ISDN (Recommendation X.31) could also be considered as a Type I subnetwork. As specified in Recommendation X.300, the interworking arrangement between two Type I subnetworks should |
be |
based |
on |
|||
|
Recommendation X.75. B.3 IWF logically belonging to the PSPDN (Recommendation X.25)/ISDN (Recommendation X.31) |
The association of a PSPDN (Recommendation X.25)/ISDN (Recommendation X.31) with an IWF together behaves like a user terminal requesting I.122 service from an ISDN (Recommendation I.122). Therefore, the interworking arrangement can be based on Recommendation I.122.
In this arrangement, interworking based on either call control mapping or port access is possible. When port access method is used, existing call control procedures in Recommendation X.25 are used for the control of virtual circuits.
Fascicle III.7 -- Rec. I.122 21
|
ANNEX C (to Recommendation I.122) Support of network layer service (X.213) in an ISDN offering additional packet mode bearer services |
Figure B-1/I.122, p. |
C.1 Network layer service can be provided by using the X.25-based additional packet mode bearer service. In this case the mapping concerns enhanced Recommendations I.451 and X.25 data transfer functions. In the case of frame switching and frame relaying, the network layer service can be provided through the use of enhanced Recommendation I.451, with, in addition:
a) additional end system functionality, or
b) enhanced I.441 functions.
C.2 C-plane enhancements
Recommendation I.451 should be enhanced so that the OSI network service parameters can be paired with Recommendation I.451 messages and information elements for all bearer services. Serveral enhancements to Recommendation I.451 are needed to convey all connection establishment and release primitives and parameters in relevant I.451 protocol elements.
22 Fascicle III.7 -- Rec. I.122
C.3 U-plane enhancements
For frame switching and frame relaying, there are two different approaches for the mapping of data transfer primitives into protocol elements:
1) layer 3 protocol elements supported by a DTE specific protocol which is transparent for the network (preferably X.25 PLP), and
2) I.441 protocol elements enhanced to map directly into the OSI network service data transfer primitives.
Further study is required for the selection and detailed definition of one of the two options.
ANNEX D
(to Recommendation I.122)
Congestion control in frame relaying service
Note -- This Annex does not cover congestion control in frame switching and X.25-based additional packet mode bearer services. This is because in these services, there is termination of user data transfer protocol in the network and so existing mechanisms for congestion control can be used.
D.1 General objectives of congestion control
The term ``congestion control'' as used here refers to a set of mechanisms incorporated to attain certain network performance objectives, particularly in the peak periods, while optimizing or improving the network resource requirements.
1) The network should, with high probability, meet the Quality of Service in terms of throughput, delay and availability negotiated with the user. Therefore, the number of occurrences of user perceived congestion should be minimized.
2) Under heavy load, the network should not allow user interference to the extent where one user can monopolize network resource usage at the expense of other users.
Specific congestion control mechanisms to achieve these objectives are for further study. One possible approach of congestion control is presented below.
D.2 User reaction to network congestion
The network has no other direct control on the data flow of a user other than dropping frames. It does so without sending explicit congestion control messages to the user. Frame discard by a network may have charging implications. This requires further study.
Users should reduce their information transfer rate when they perceive the impact of network congestion. Reduction of throughput by a user may well result in an increase of the effective throughput available to the user during congestion.
It is suggested that a user of frame relaying 1 service implement some form of congestion-sensitive adaptation function that has the following characteristics:
i) no blocking of data flow under normal conditions,
ii) reduction to a lower throughput upon detection of network congestion,
iii) progressive increase to the maximum negotiated throughput upon congestion abatement.
For frame relaying 2 service, the user is required to implement the above congestion-sensitive adaptation function through the use of the windowing mechanism in Recommendation I.441. In this case, the user will base the detection of congestion on events available in the I.441 elements of procedure (e.g. receipt of a REJECT frame, detection of frame loss, etc.). The user dynamically adjusts its window size in accordance with network congestion condition.
Fascicle III.7 -- Rec. I.122 23
D.3 Control action by the network congestion
Users of frame relaying services should reduce their information transfer rate when they perceive the impact of network congestion (see § 2). But the network cannot rely solely on the user's behaviour to control network congestion. This is the case for both frame relaying 1 and frame relaying 2 services.
The network should monitor the throughput of each call/interface and exercise a frame discard strategy under congestion conditions, for those calls/interfaces that exceed their negotiated throughput. However, because congestion can occur even when the calls do not exceed their negotiated throughput (e.g. network failures), the network should discard frames in a way that assures some fairness among users.
The selection of mechanism(s) which may be used by the network for this purpose are for further study.
Blanc
24 Fascicle III.7 -- Rec. I.122
SECTION 3
GENERAL MODELLING METHODS
METHOD FOR THE CHARACTERIZATION OF TELECOMMUNICATION
SERVICES SUPPORTED BY AN ISDN AND NETWORK
CAPABILITIES OF AN ISDN
(Melbourne, 1988)
The concept and the principles of ISDNs are described in Recommendation I.120. The purpose of this Recommendation is to provide a method for the characterization of telecommunication services (including supplementary services) and a definition of the needed network capabilities in an ISDN, in order to support the identified services.
|
The main objectives are: a) to give a common framework and tools to be adopted for service description; b) to show how, starting from the service definition, it is possible to define protocols |
and network resources for providing such services; |
|
|
c) to make reference to those Recommendations which are relevant to the above |
two points. |
The method is divided into three main stages of activity: service aspects (stage 1), functional network aspects (stage 2) and network implementation aspects (stage 3).
Within each stage a number of steps have been identified, as shown in Figure 1/I.130. In principle, the application of the method is sequential, stage 1 given the service description from the user point of view, stage 2 offering an intermediate view of what happens at the user-network interface and inside the network between different exchanges, and stage 3 giving the actual switching and service nodes descriptions, as well as protocols and format to be adopted.
In order to classify and relate the various Recommendations relevant to the method, a three level structure is used where each level applies to the three above-mentioned stages.
Level 1 is a description of the overall method, and is contained in this Recommendation.
Level 2 identifies and defines the tools for the work within each stage. Examples of these tools are frameworks for service prose descriptions, libraries of pre-defined functions, graphical conventions, etc. All these tools are covered by Recommendations.
Level 3 is the actual application of the method to each individual service and is contained in various Recommendations.
The application of the method for stage 1 results in a description of the service. Stage 2 results in one or more implementation independent scenarios, and stage 3 results in a set of protocol and switching Recommendations needed to realize the service for each scenario.
Figure 2/I.130 illustrates the concept of levels in relation to various Recommendations relevant to the method.
Fascicle III.7 -- Rec. I.130 25
Figure 1/I.130, p. 8 26 Fascicle III.7 -- Rec. I.130
Figure 2/I.130, p. 9 Fascicle III.7 -- Rec. I.130 27
|
As referred to in § 2 above, there are three stages of the method as follows: Stage 1 is an overall service description from the user's standpoint. Stage 2 is an overall description of the organization of the network functions to map service requirements into network capabilities. Stage 3 is the definition of switching and signalling capabilities needed to support services defined in stage 1. Each stage consists of several steps. |
||
|
3.1 |
Stage 1 Stage 1 is an overall service description from the user's point of view, but does not deal with the details of the human interface itself. The |
stage 1 service description is independent of the amount of functionality in the user's terminal, other than that required to provide the human interface. For example the conference calling service description is designed to be independent of whether the conference bridge is in the terminal, in the serving exchange or elsewhere.
The steps in stage 1 are:
Step 1.1 -- Service prose definition and description
This step describes the service in terms of the perceptions of the user receiving the service and any other users involved in the service. It describes events in a generic term which does not constrain terminal or network design. It is intended to allow an understanding of the service without regard to implementation. The description should include operational, control, interworking and administrative aspects as well as interactions with other sevices. A detailed format and list of definitions for terms used for service prose definition and description is contained in Recommendation I.210.
Step 1.2 -- Static description of the service using attributes
The static, that is, time-independent, aspects of a service can, in some cases, be efficiently described by attributes. An attribute is a characteristic or functional description which is common to several services and therefore needs to be described in detail only once. Subsequently, it can be referred to by a name or other designation. Within the scope of an attribute definition there may be multiple parameters or identified functional variations which are called attribute values.
The attribute technique is described more fully in Recommendation I.140. It contains an outline of the technique and definitions of attributes and attributes values, valid for both services and connection types. The attributes and attribute values identified for services can be found in Rec. I.210 (Annexes B and C) for bearer services and for teleservices. The use of the attribute technique in the description of supplementary services is for further study.
Step 1.3 -- Dynamic description of the service using graphic means
The dynamic description of a service contains all the information that is sent and received by the user from activation invocation of the service to completion of the service. The information is presented in the form of an overall Specification and Description Language (SDL) diagram. An overall SDL diagram is a flow chart which identifies all possible actions relevant to the service as perceived by the user. It treats the network as a single entity, that is, no information flows within the network are considered. The method of using the overall SDL diagrams for service description is given in Recommendation I.210, Annex D.
3.2 Stage 2
Stage 2 identifies the functional capabilities and the information flows needed to support the service as described in stage 1. The stage 2 description will also include user operations not directly associated with a call (e.g. user change of call forwarding parameters via his sevice interface) as described in stage 1. Furthermore, it identifies various possible physical locations for the functional capabilities. The output of stage 2 which is signalling system independent is used as an input to the design of signalling system and exchange switching Recommendations.
28 Fascicle III.7 -- Rec. I.130
The steps in stage 2 are:
Step 2.1 -- Derivation of a functional model
A functional model is derived for each basic and for each supplementary service. The functions required to provide the service are grouped into functional entities. The functional model is the aggregate of the functional entities and their relationships. The concept of a functional entity is contained in the ISDN functional principles Recommendation (I.310). In the case of supplementary services the relationship between the supplementary service and the basic service is shown by a composite functional model.
Step 2.2 -- Information flow diagrams
The distribution of the functions needed to provide a service as defined by the functional model requires that interactions be defined between functional entities. Such an interaction is referred to as an `` information flow '' and has a name descriptive of the intent of the information flow. Information flow diagrams are created for successful operation and may be created as appropriate for other cases. The semantic meaning and information content of each information flow is determined.
Step 2.3 -- SDL diagrams for functional entities
The functions performed within a functional entity are identified and represented in the form of a Specification and Description Language (SDL) diagram. The inputs and outputs of the SDL diagram are to and from the users as described in stage 1 and are information flows to and from other functional entities.
SDL diagrams are defined for each functional entity based on the information flows defined for the successful operation of the service. The SDL diagram also covers the unsuccessful cases.
Step 2.4 -- Functional entity actions
The actions performed within a functional entity are represented as a list, or sequence, of functional entity actions (FEAs) in prose form. These form the basis for understanding the meaning of the information flows and provide a basis for the stage 3 switching Recommendations.
Note -- The relationship between the FEAs and the elementary functions (EFs), as listed in Recommendation I.310 is for further study.
Step 2.5 -- Allocation of functional entities to physical locations
In this step, the functional entities and information flows identified in previous steps are allocated to specific types of physical locations, e.g. a PABX or an exchange. Each allocation is called a scenario. The relationship supported between two functional entities located in different physical locations must be realized wihin protocol(s) supported between those locations.
The detailed procedures and formats used and the concepts needed for the stage 2 description can be found in Recommendations Q.65 and I.310.
3.3 Stage 3
In stage 3 the information flow and SDL diagrams from the stage 2 output form the basis for producing the signalling system protocol Recommendations and the switching Recommendations.
The steps in stage 3 will need to be repeated for each service where, because of different allocations of functional entities to physical locations, different protocols and procedures are needed.
The steps in stage 3 are:
Step 3.1 -- Protocols and formats
The messages needed to support the information flows and the modifications to existing information flows between the nodes are identified and the detailed message elements and procedures are designed into the relevant signalling systems.
Step 3.2 -- Switching and service nodes
The requirements identified for switching functions (functional entity actions) are incorporated into the switching Recommendations (Q.500-Series).
Fascicle III.7 -- Rec. I.130 29
MONTAGE : PAGE 84 = PAGE BLANCHE 30 Fascicle III.7 -- Rec. I.130
SECTION 4
TELECOMMUNICATION NETWORK AND SERVICE ATTRIBUTES
ATTRIBUTE TECHNIQUE FOR THE CHARACTERIZATION OF
TELECOMMUNICATION SERVICES SUPPORTED BY AN
ISDN AND NETWORK CAPABILITIES OF AN ISDN
(former Recommendation I.130 of the Red Book;
amended at Melbourne, 1988)
The purpose of this Recommendation is to introduce the attribute technique and to describe attributes and list attribute values. Attributes are used in the characterization of services and network capabilities provided by an ISDN. The attribute technique can also be used to describe the salient features of other objects of study in telecommunications, e.g. charging.
This Recommendation (in the general I.100-Series) will act as a library of all attributes and attribute values used in other I-Series Recommendations. The inclusion of a particular attribute value in this Recommendation does not mean that this particular object is being recommended by CCITT, but that it is a potential attribute (or attribute value) which may be used in a particular Recomendation in the I-Series (e.g. to describe a CCITT-recommended service).
Annex A includes all attributes and their values so far identified and defined.
2.1 Outline of the technique
This technique is used to describe objects in a structured, simple manner and to highlight the important aspects of the object. In order to be able to identify comparable objects, e.g. bearer services, the general concept of the object is broken down in a number of salient features. The salient features are termed attributes . | ach attribute is independent of the others so that a change in the value of one will not affect the others. To describe a particular object the attributes are assigned values which identify that object.
|
It is not always necessary or useful to describe an object in great detail and so attributes have been graded into three levels: -- dominant attributes : these define a sub-set containing similar objects, this sub-set is termed a class or category; -- secondary attributes : these define a particular object; and -- qualifying attributes : these define variants of an object. Characterization of attributes should be used in the I-Series of Recommendations when appropriate. Fascicle III.7 -- Rec. I.140 31 |
2.2 Basic rules
|
-- -- used. -- |
Each attribute is assigned a name and definition. Some attributes may apply to only one object, others may be applicable to several objects. In this case the same attribute name is A given value should have the same name and definition in all Recommendations. |
|
|
-- -- 2.3 2.3.1 |
Depending on the nature of the object described, a particular attribute may need to be used more than once. Each attribute should be described by three perspectives; generic, service and network. Attribute lists Generic attributes |
|
2.3.2 |
Information transfer mode Information transfer rate Information transfer capability Establishment Symmetry Configuration Structure Channel (rate) Control protocol Information transfer protocol Performance Interworking Operations Type of user information High layer protocol Note -- This list will be completed according to further results on studies of connectionless, multi-media, broadband and mobile services. Service attributes |
2.3.2.1 Bearer services
1 Information transfer mode
2 Information transfer rate
Service information transfer rate considered at the access point.
32 Fascicle III.7 -- Rec. I.140
|
3 4 5 6 7 8 9-1 9-2 9-3 |
Information transfer capability Structure Establishment of communication Symmetry Communication configuration Access channel and rate Signalling access protocol layer 1 Signalling access protocol layer 2 Signalling access protocol layer 3 |
|
Information access protocol (layer 1-3) at the access point. 9-5 Information access protocol layer 2 9-6 Information access protocol layer 3 10 Supplementary services provided 11 Quality of service 12 Interworking possibilities 13 Operational and commercial |
9-4 |
Information access protocol layer 1 |
|||
|
Fascicle III.7 |
-- Rec. I.140 33 |
2.3.2.2 Teleservices
1, 2, 3, 4, 5, 6, 7, 8, 9-1, 9-2, 9-3, 9-4, 9-5, 9-6: refer to § 2.3.2.1.
10 Type of user information
|
11 12 13 14 15 16 17 18 2.3.2.3 |
Layer 4 protocol Layer 5 protocol Layer 6 protocol Layer 7 protocol Supplementary services provided Quality of service Interworking possibilities Operational and commercial Supplementary services |
For further study.
|
2.3.2.4 Charging For further study. 2.3.3 Network attributes 2.3.3.1 Connection types |
types |
|
1 2 3 4 5 6 7 8 9 10 |
Information transfer mode Information transfer rate Information transfer susceptance Establishment of communication Symmetry Connection configuration Structure Channel (rate) Connection control protocol Information transfer coding/protocol |
11 Network performance
Information transfer rate is considered between access points.
Information transfer protocol is considered between access points.
34 Fascicle III.7 -- Rec. I.140
|
12 13 2.3.3.2 1 2 3 4 5 6 7 8 9 10 11 12 13 |
Network interworking Operations and management Connection elements Information transfer mode Information transfer rate Information transfer susceptance Establishment of communication Symmetry Connection configuration Structure Channel (rate) Connection control protocol Information transfer coding/protocol Network performance Network interworking Operations and management |
Fascicle III.7 -- Rec. I.140 35 |
2.3.3.3 Other network entities
|
The definition of attributes for basic connection components, and network capabilities to support supplementary services needs further |
||
|
study. 2.4 |
Attribute definition |
|
|
A list of definitions of attributes and attribute values is contained in Annex A to this Recommendation. |
||
This technique has been applied in I.200-Series Recommendations for the specification of the telecommunications services supported by and ISDN and in Recommendation I.340 for the characterization of ISDN connection types and connection elements.
|
The application of the attribute technique for the characterization of multi-media services is for further study. ANNEX A (to Recommendation I.140) List of definitions of attributes and attribute values |
|||
|
A.1 A.1.1 |
Definitions of the attributes Telecomunication service attribute definitions |
|
Information transfer mode This attribute describes the operational mode for transferring (transporting and switching) user information through the ISDN. Possible values : -- circuit -- packet |
Information transfer rate
This attribute describes either the bit rate (circuit mode) or the throughput (packet mode). It refers to the transfer of digital information at the access points.
Possible values : -- appropriate bit or throughput rate
Information transfer capability
This attribute describes the capability associated with the transfer of different types of information through the ISDN.
36 Fascicle III.7 -- Rec. I.140
|
Possible values : -- speech -- 3.1 kHz audio -- 7 kHz audio -- 15 kHz audio -- video -- other values |
-- unrestricted digital information |
Fascicle III.7 -- Rec. I.140 37 |
Structure
This attribute refers to the capability of the ISDN to deliver information to the destination access point or reference point in a structure (e.g. time interval for circuit mode, service data unit for packet mode), that was presented in a corresponding signal structured at the origin (access point or reference point).
|
Possible values : -- 8 kHz integrity -- service data unit integrity -- time slot sequence integrity -- restricted differential time delay -- unstructured |
Establishment of communication
This attribute describes the mode of establishment associated to the telecommunication service used to establish and release a given communication.
|
Possible values : -- reserved -- permanent Symmetry |
-- demand |
This attribute describes the relationship of information flow between two (or more) access points or reference points involved in a communication.
Possible values : -- unidirectional
-- bidirectional symmetric
-- bidirectional asymmetric
Communication configuration
This attribute describes the spatial arrangement for transferring information between two or more access points. It completes the structure associated with a telecommunication service as it associates the relationship between the access points involved and the flow of information between these access points.
Possible values : -- point-to-point
-- multipoint
38 Fascicle III.7 -- Rec. I.140
-- broadcast
Access channel and rate
This attribute describes the channels and their bit rate used to transfer the user information and/or signalling information at a given access point.
Possible values : -- name of the channel (letter) and the corresponding bit rate
|
Note -- This attribute can be used several times for communication characterization. Signalling access protocol layer 1-3, information access protocol layer 1-3 These attributes characterize the protocol on the signalling or user information transfer channel at a given access point or reference point. Possible values : -- appropriate protocol |
Fascicle III.7 -- Rec. I.140 39
|
Type of user information Possible values : -- speech -- sound -- text -- facsimile -- text-facsimile -- videotex -- video -- text-interactive |
Layer 4 -- 7 protocol
These attributes characterize the protocol on the user information transfer channel at a given access point or reference point. Possible values : -- appropriate protocol
|
Supplementary services provided This attribute refers to the supplementary services associated with a given telecommunication service. Quality of service This attribute is described by a group of specific sub-attributes, for example: service reliability, service availability. The values are under study. Interworking possibilities To be defined. Operational and commercial To be defined. A.1.2 Connection type attribute definitions |
Information transfer mode
40 Fascicle III.7 -- Rec. I.140
This attribute describes the operational mode for transferring (transporting and switching) user information through the ISDN.
Possible values : -- circuit
-- packet
Information transfer rate
This attribute describes either the bit rate (circuit mode) or the throughput (packet mode). It refers to the transfer of digital information between access points or reference points.
|
Possible values : -- appropriate bit or throughput rate Information transfer susceptance This attribute describes the capability associated with the transfer of different types of information through the ISDN. Possible values : -- unrestricted digital information -- speech -- 3.1 kHz audio -- 7 kHz audio -- 15 kHz audio -- video -- other values |
Fascicle III.7 -- Rec. I.140 41
|
Establishment of connection This attribute describes the mode of establishment used to establish and release a given connection in an ISDN. Possible values : -- demand -- semi-permanent -- permanent |
|
Symmetry This attribute describes the relationship of information flow between two (or more) access points or reference points of a connection. Possible values : -- unidirectional -- bidirectional symmetric -- bidirectional asymmetric |
Connection configuration
This attribute describes the spatial arrangement for transferring information on a given connection. It consists of two sub-attributes, topology and dynamics.
Structure
This attribute refers to the capability of the ISDN to deliver information to the destination access point or reference point in a structure (e.g. time interval for circuit mode, service data unit for packet mode), that was presented in a corresponding signal structured at the origin (access point or reference point).
|
Possible values : -- 8 kHz integrity -- service data unit integrity -- time slot sequence integrity -- restricted differential time delay -- unstructured |
Channel (rate)
This attribute describes the channels and their bit rate used to transfer the user information and/or signalling information at a given access point.
Possible values : -- name of the channel (letter) and the corresponding bit rate
42 Fascicle III.7 -- Rec. I.140
Note -- This attribute can be used several times.
Connection control protocol, information transfer coding/protocol
These attributes characterize the protocol/coding on the signalling or user information transfer channel at a given access point or reference point.
Possible values : -- appropriate protocol or coding
Network performance
This attribute describes the network performance that relates to an ISDN connection.
Fascicle III.7 -- Rec. I.140 43
|
This performance attribute consists of sub-attributes, for example: Error performance : the values are given in the appropriate Recommendations. Slip performance : the values are given in the appropriate Recommendations. The definition of further sub-attributes is for further study. Network interworking To be defined. Operation and management To be defined. A.1.3 Connection element attribute defintions |
|
Information transfer mode This attribute describes the operational mode for transferring (transporting and switching) user information through the ISDN. Possible values : -- circuit -- packet |
Information transfer rate
This attribute describes either the bit rate (circuit mode) or the throughput (packet mode). It refers to the transfer of digital information between access points or reference points.
|
Possible values : -- appropriate bit or throughput rate Information transfer susceptance This attribute identifies equipment which may restrict the types of information which may pass through the ISDN. Possible values : -- speech processing equipment -- echo suppression equipment -- multi-satellite hope -- null 44 Fascicle III.7 -- Rec. I.140 |
|
Establishment of connection This attribute describes the mode of establishment used to establish and release a given connection element in an ISDN. Possible values : -- demand -- semi-permanent -- permanent |
Symmetry
This attribute describes the relationship of information flow between two (or more) access points or reference points of a connection element.
Fascicle III.7 -- Rec. I.140 45
Possible values : -- undirectional
-- bidirectional symmetric
-- bidirectional asymmetric
Connection configuration
This attribute describes the spatial arrangement for transferring information across a given connection element. It consists of two sub-attributes, topology and uniformity.
Structure
This attribute refers to the capability of the ISDN to deliver information to the destination access point or reference point in a structure (e.g. time interval for circuit mode, service data unit for packet mode), that was presented in a corresponding signal structured at the origin (access point or reference point).
|
Possible values : -- 8 kHz integrity -- service data unit integrity -- time slot sequence integrity -- 8 kHz integrity with restricted differential time delay -- unstructured |
Channel (rate)
This attribute describes the channels and their bit rate used to transfer the user information and/or signalling information at a given access point.
Possible values : -- name of the channel (letter) and the corresponding bit rate
Note -- This attribute can be used several times.
Connection control protocol, information transfer coding/protocol
These attributes characterize the protocol/coding on the signalling or user information transfer channel at a given access point or reference point.
Possible values : -- appropriate protocol or coding
Network performance
This attribute describes the network performance that relate to an ISDN connection element.
46 Fascicle III.7 -- Rec. I.140
This performance attribute consists of sub-attributes, for example:
Error performance : The values are given in the appropriate Recommendations.
Slip performance : The values are given in the appropriate Recommendations.
The definition of further sub-attributes is for further study.
To be defined.
To be defined.
Fascicle III.7 -- Rec. I.140 47
|
A.2 |
Definition of the attribute values unrestricted digital information Transfer of information sequence of bits at its specified bit rate without alteration. This implies: -- bit sequence independence |
This implies: -- digit sequence integrity
This implies: -- bit integrity.
speech
Digital representation of speech coded according to a specified encoding rule (e.g. A-law, m-law).
3.1 kHz audio
Digital representation of audio information such as voice-band data and speech with a bandwidth of 3.1 kHz, the encoding rule being specified (e.g. A-law, m-law).
7 kHz audio
Digital representation of audio information with a bandwidth of 7 kHz, the encoding rule being specified.
15 kHz audio
Digital representation of audio information with a bandwidth of 15 kHz, the encoding rule being specified.
video
Digital representation of video image information, the encoding rule being specified.
8 kHz integrity
This value applies when:
i) at each user-network interface, intervals of 125 ms are implicitly or explicitly demarcated, and
ii) all bits submitted within a single demarcated 125 ms interval are delivered within a corresponding single demarcated 125 ms interval.
service data unit integrity
This value applies when:
i) at each user-network interface, protocols provide a mechanism for identifying the boundaries of service data units (e.g. X.25 complete packet sequence), and
ii) all bits submitted within a single service data unit are delivered in a corresponding service data unit.
unstructured
48 Fascicle III.7 -- Rec. I.140
This value is applicable when the telecommunication service or connection neither provides structural boundaries nor preserves structural integrity.
demand (communication)
The communication can be started as soon as possible after the request is made (e.g. t1 -- t0is as short as possible).
Communication and connection release occurs in response to the request of any of the users (calling or called users), t3 -- t2is as short as possible (see Figure A-1/I.140).
Fascicle III.7 -- Rec. I.140 49
|
reserved (communication) |
Figure A-1/I.140, p. |
The communication can be started at time instant t1explicitly specified at the time instant of communication and connection request, t0. Communication and connection release occurs at time instant t3explicitly specified also at t0. Communication and connection duration is predetermined: the communication and connection is set up for a specified period of time. As an option, connection release occurs at time instant t3following a release request made at time instant t2during the communication and a priori undetermined (t3 -- t2is as short as possible). This option corresponds to an unspecified duration of the communication and connection, or to a possibility of unanticipated release (see Figure A.1/I.140).
permanent (communication)
The communication can be started after the connection is set up at time instant t1in response to a subscription request for the service at time instant t0. the duration may be unspecified. The communication and connection is released at time instant t3corresponding to the end of the subscription.
switched (connection)
ISDN circuit switched connections/connection elements are set up at any time on demand via e.g. a bit channel in response to signalling information received from subscribers, other exchanges or other networks, i.e. on a per-call-basis. Message/packet switched connections/connection elements provided by an ISDN may be set up on demand via circuit-mode channels (e.g. B-channels) and special packet switching units or via the D-channel subject to any D-channel priority/flow control restrictions that may be applicable.
|
Note -- A more general definition of this value is also given in Recommendation I.112 (No.311). semi-permanent (connection) Semi-permanent connections/connection elements pass through a switching network. Semi-permanent connections/connection elements between agreed points may be provided |
for an indefinite period of time after |
|
subscription, for a fixed period or for agreed periods during a day, week or other interval. 50 Fascicle III.7 -- Rec. I.140 |
permanent (connection)
Permanent connections/connection elements are described by the following characteristics:
Permanent connections/connection elements are available to the connected subscriber at any time during the period of subscription between fixed network destination points requested by the subscribers.
unidirectional
This value applies when the information flow of messages is provided only in one direction.
bidirectional symmetric
This value applies when the information flow characteristics provided by the service are the same between two (or more) access points or reference points in the forward and backward directions.
bidirectional asymmetric
This value applies when the information flow characteristics provided by the service are different in the two directions.
point-to-point communication
This value applies when there are only two access points.
multipoint communication
This value applies when more than two access points (see Note) are provided by the service. The exact characteristics of the information flows must be specified separately based on functions provided by the ISDN.
Note -- The number of access points can be undefined.
broadcast communication
This value applies when more than two access points (see Note) are provided by the service. The information flows from a unique point (source) to the others (destination) in only one direction.
|
Note -- The number of destination access points is undefined. point-to-point connection This value applies when only two end points are provided by the connection. multipoint connection This value applies when more than two end points are provided by the connection, and thus many different information flows are possible. broadcast connection To be defined. Fascicle III.7 -- Rec. I.140 51 |
|
simple connection A connection consisting of only one connection element. tandem connection Two or more connection elements in series form a connection. |
52 Fascicle III.7 -- Rec. I.140
parallel connection
Two or more connection elements in parallel form a connection.
star
To be defined.
mesh
To be defined.
uniform
This value applies when all connection elements have the same attribute values.
non uniform
This value applies in all other cases.
concurrent
The configuration of a connection is described as concurrent when all of the connection elements involved are established simultaneously and released simultaneously.
sequential
A connection has a sequential configuration when its connection elements are established and released sequentially i.e. only one of several connection elements or chains of connection elements exists at any given time.
add/remove
When connection elements can be established and released while other connection elements of the same connections still exist, the configuration of this connection is described as add/remove.
Symmetry and/or topology change
When the symmetry attribute value of the connection element can be changed during a call.
Time slot sequence integrity
This value applies when
i) at each user-network interface, time slots are implicitly or explicitly demarcated for each access channel of an aggregate of access channels, and
ii) the information parts delivered from the time slots at the receiving end are in the same order as submitted at the transmitting end.
Note -- Preserving the order of bits within an individual time slot from the transmitting to the receiving end is not part of this definition.
Fascicle III.7 -- Rec. I.140 53
8 kHz integrity with restricted differential time delay (RDTD)
This value applies when the following conditions are met:
-- that at each point in a connection or connection element, time slots are explicity or implicitly demarcated for each information channel or an aggregate of information channels; and
-- that the information parts submitted to the time slots at the transmitting end are delivered to the receiving end with a differential time delay of not more than 50 ms (provisional).
54 Fascicle III.7 -- Rec. I.140
ISDN NETWORK CHARGING CAPABILITIES ATTRIBUTES
(Melbourne, 1988)
On the basis of charging principles provided in the D.200-Series, this Recommendation covers the method for identifying the network charging capabilities and provides a candidate list of attributes in Annex A.
ISDNs shall support a range of services as defined in the I.200-Series of Recommendations. Charging capabilities and mechanisms need to be associated with each service.
To ensure that service charging requirements may be supported by network charging facilities, it is essential that the service requirements be specified in a format which simplifies the identification of network requirements. The attribute technique is considered an appropriate mechanism by which service requirements may be related to network requirements and has thus been utilized in this Recommendation. (See Figure 1/I.141.)
Figure 1/I.141, p. 3 ISDN services characteristics
Specifically, the services to which network charging capabilities attributes should be applied are as given in Table 1/I.141.
H.T. [T1.141]
TABLE 1/I.141
center box; cw(90p) | cw(78p) . Service Recommendations _ lw(90p) | cw(78p) . Bearer services I.230-Series lw(90p) | cw(78p) . Teleservices I.240-Series lw(90p) | cw(78p) . Supplementary services I.250-Series _
Table 1/I.141 [T1.141], p.
Fascicle III.7 -- Rec. I.141 55
For each service defined in the I.200-Series Recommendations, one set of attribute values should be selected for each network charging capability attribute. Assignment of attribute values for a specific service will allow the determination of the network requirements relating to this service.
The definition of charging requirements in terms of network charging capability attributes is intended to provide a link between the service charging characteristics and the respective network charging mechanisms.
Network charging capability attributes are also intended to indicate the range of information to be transferred either within the signalling network or by some other means.
Annex A lists the candidate network charging capability attributes and the possible values so far identified.
ANNEX A
(to Recommendation I.141)
Candidate network charging capability attributes
H.T. [T2.141]
TABLE A-1/I.141
center box; cw(78p) | cw(90p) . Attribute Possible values _ lw(168p) . Charging capabilities _ lw(78p) | lw(90p) . Usage | ua)
requested Call attempt | ub) { Service
} _ lw(78p) | lw(90p) . ModulationCall set-up DurationDistanceVolumeTime ofBasisusageof provision_ lw(168p) . Billing capabilities _ lw(78p) | lw(90p) . Billing identification { Calling party (sent paid) Called party (reverse/collect) Transferred (third party)
} _ lw(78p) | lw(90p) . Collection { Subscriber billing Credit card Coin box Debit card
} _ lw(78p) | lw(90p) . Mode { On line Off line
}
a) The identification and definition of values for supplementary services (e.g. registration, activation) is for further study.
|
b) |
||
|
For further study. |
||
|
Tableau A-1/I.141 [T2.141], p. 13 |
||
|
56 Fascicle III.7 -- |
Rec. I.141 |
Fascicle III.7 -- Rec. I.141 57
58 Fascicle III.7 -- Rec. I.141