ISDN FAQ |
FAQs on ISDN
|
|
How can a user program an application so that a specific protocol is used throughout the course of the call ?
| This depends upon the way the layer 3 protocol, (see Q931 messages formats) is programmed. |
|
|
| Q931 is a layer 3 ISDN protocol. Together with the help of its associated layer two, Q921 (LAPD Protocol) and the physical layer 1 protocol, it implements call control procedures over the ISDN. It does this by specifying the way layer 3 messages employ the D channel to establish, control and tear down a call for its associated B channel. Key elements of Q931 messages formats are shown separately. |
|
|
What is the key programmable part of the layer three protocol for call establishment ?
| The Bearer Channel Capability Information Element (BCC IE). |
|
|
| It comprises one or more octets included in layer three messages to provide additional information associated with the main message field. |
|
|
With what Message Field is the BCC IE associated ?
| With the 'Setup Message' in the Main Message field. This is the first layer three message used during call establishment and its function is seen in the signalling sequences . (Additional IEs may also be associated with the Setup message and may be used to control a call in a variety of ways as required by the application to be implemented). |
|
|
What information is contained in the BCC IE ?
| The BCC IE has two key functions. These are implemented in a manner defined by the way its information fields are coded. The task of these information fields is to: (i) select the Bearer Services in the network which are needed to support the application to be implemented after call establishment. (ii) check destination terminal compatibility and also support connections to destination terminals in different networks. Various examples of the way the information fields may be coded are shown in Tables 1, 2, 3, 4, 5, 6, 7, 8, 9. |
|
|
How is a Bearer Service defined ?
| It is the set of services which the ISDN will support between the S Reference Points of ISDN terminals connected over the ISDN. It is fully described by both its Attributes and the Values associated with these Attributes. |
|
|
How are the Attributes defined in the BCC IE ?
| This information is contained in octets 3 and 4 and 5 (as well as octets 6 and 7 for X25 connections) of the IE. (Octet 1 lists the code which designates the BCC IE and octet 2 describes the number of octets to follow with the BCC IE information). |
|
|
What determines the value of the attributes ?
| The format of the BCC IE is determined by the application which is to be supported by the ISDN. |
|
|
What information is contained in Octet 3 of the BCC IE ?
| Octet 3 of the BCC IE contains information on the 'Information Transfer Capability' attribute and associated values, viz. speech, unrestricted digital information transfer (UDI) or restricted digital transfer (RDI), 3.1 khz audio, 7 khz audio or video. |
|
|
What information is contained in Octet 4 of the BCC IE ?
| Octet 4 contains information about the 'Transfer Mode' attribute and associated values, i.e. circuit or packet mode, and also the 'Information Transfer Rate' attribute and associated values, i.e. 64 kbit/sec, 2x64 kbit/sec, 384 kbit/sec, 1536 kbit/sec or 1920 kbit/sec. |
|
|
What information is contained in Octet 5 of the BCC IE ?
| Octet 5 describes the coding required at layer one for the information transfer capability, i.e. the coding format of B channel information implemented at layer 1. This information may be modified by the network (to allow interworking with another type of network, for example). It may be included with the Setup message at the start of call establishment by the originating terminal. |
| It may be omitted (see the Note below) in the BCC IE with the Setup message and included in the Low Layer Compatibility Information Element which is used in the final stages of call establishment for compatibility checking. This latter case is discussed in detail below. |
| Note: If the transfer mode is 'circuit mode' and if the information transfer capability is 'unrestricted digital information' or 'restricted digital information', and if the user information layer 1 protocol is not to be identified to the network, octet 5 shall be omitted. If the transfer mode is packet mode, octet 5 may be omitted. Otherwise octet 5 shall be present. |
|
|
What information is contained in Octets 5a and 5b ?
| Information on the Rate Adaption protocols, V110 and V120, respectively. Rate adaption employs UDI and RDI transfer capability and 5b contains negotiation elements which are employed as discussed below (see Low Layer Compatibility Negotiation). |
|
|
Why may the information in the BCC IE be modified by the network ?
| This is explained by the following examples: |
| Example1: Say the originating terminal intends to establish a speech connection. Then octet 5 should be encoded for A-law or u-law pcm. Say A-law is chosen because it is supported by the originating network. If the terminating network is an ISDN employing u-law pcm then the inter-networking capability will convert the outgoing data into the appropriate u-law code and thus ensure compatibility with the equipment at the terminating side |
| Example2: If the originating terminal wants to establish a UDI transfer with rate adaption then the BCC IE will include the value and type of the rate adaption required in octet 5, e.g. V110 at 9.6 kbit/sec. If the terminating equipment is ISDN compatible then no internetworking is required. If the terminating equipment is a terminal in the PSTN then an internetworking function (if available) can be activated to establish the connection. (See Notes 1 and 2 below). |
| The Low Layer Compatibility IE is unchanged by the network and in these examples if the information was not contained in the BCC IE then the call could not be established. See Low Layer and BCC IE Compatibility Issues. |
| Note 1: ISDN Terminal Equipment (TE) may include modem chips to support calls to terminating modems in the PSTN. |
| Note 2: The internetworking function is also required to support GSM to ISDN Connectivity. See also the role of the Progress Indicator IE in relation to internetworking. |
|
|
Provide examples of how the BCC IE is coded to cater for different attributes and values required to support specific applications over the ISDN.
| See Tables 1, 2, 3, 4, 5, 6, 7, 8, 9. |
|
|
As part of the call establishment process how is the call routed over the ISDN to the distant terminal(s) ?
| By means of the Called Number IE which, along with the BCC IE, is part of the Setup message. |
|
|
Does the Address Field in layer 2 (LAPD) at the originating end play any part in the routing process ?
| No, not in the routing process but in the way the layer 3 information is transferred by the TE to its layer 2 peer at the originating Local Exchange (LE). |
|
|
How is the Layer 3 Message transmitted over the network ?
| By means of the ISDN User Part (IUP) of Common Channel Signalling System No. 7 (CCSS7 IUP). |
|
|
How must the incoming side prepare for the reception of the Setup message sent from the originating side ?
| All the Applications associated with ISDN Terminal Equipment (TE) must be in the listen state. They indicate this condition to the API which they employ to communicate with layer 3 of their TE as shown in Figure 1 which shows the relationship between CAPI messages and Layer three messages. |
| This state ensures that messages which are incoming to layer 3 in the TE can communicate with the applications. |
|
|
How is a connection established ?
| A connection may be established if (i) addressing and (ii) compatibility issues indicate a match between the incoming call and an application. |
|
|
Can other methods be employed for TE selection ?
| Yes, by means of a local procedure between the ISDN exchange and terminal(s) in the customers premises. This involves the use of Logical Terminal Profile (LTP) and the TEI part of the Address Field in LAPD. |
|
|
What addressing issues are involved ?
| The address, which may be a subaddress or DDI information sent by the local exchange to the terminal, may provide a match with the one addressed terminal in the case of a point to point connection or with one specific terminal in the case of a point to multipoint connection. |
| (The LAPD addressing information supports point to point or point to multipoint calls). |
| Multiple Subscriber Numbers (MSN) may be used to identify a particular TE. In this addressing case individual TEs are assigned specific numbers. Thus one MSN may be designated for use as a fax terminal, the next for an ISDN phone, the next for a PC which caters for datacommunications and so on. |
|
|
What are the outcomes of the addressing process ?
| The address may be 'ignored' or a match may be indicated. In the case of a mismatch of DDI or subaddressing information or in the case where the terminal has no addressing information already assigned to it then the call shall be ignored. |
|
|
What happens if the call is ignored ?
| In the case of a point to multipoint call, it will be offered to other TEs on the same S-Bus. |
|
|
In the case of a matched address, what further compatibility checks are carried out ?
| In the case where the network offers bearer services as part of the Setup message (BCC IE) then the TE at the terminating end will check that it can support the Bearer Services offered. If there is a mismatch then the call will be rejected or ignored. |
| Layer 3 of the incoming TE is associated with the application it supports in the following way: |
| The application in listen mode has a profile of the bearer services it supports. Thus a speech application, for example, with the relevant bearer parameters will answer an incoming call with corresponding bearer parameters in the BCC IE. The first application to answer with the appropriate parameters is acknowledged. |
|
|
What are the next steps in the Terminal selection process ?
| Low Layer and/or High Layer Compatibility checking is carried out (if these IEs have been sent with Layer 3 messages during the course of call establishment). This is user to user checking and can only be implemented if the relevant IEs are supported in layer 3 of the corresponding TEs. |
|
|
What will Low Layer Compatibility IE check for?
| Low layer Compatibility checking will deal with the compatibility between layers 1,2 and 3 of the calling and called terminals (assuming that the Low Layer Compatibility IE is present, i.e. has been sent with a layer 3 message). |
| However, as explained under Low Layer Compatibility IE and BCC IE Layer Compatibility Issues, compatibility in the BCC IE case will always take precedence in the event of any contradiction with results acquired in the Low Layer Compatibility check. |
|
|
What will High Layer Compatibility check for ?
| This, if present, will check for compatibility between the application to be implemented over the connection between the two TEs, i.e. teleservices compatibility. (See also the note on Supplementary Services). |
|
|
What are the possible outcomes of this compatibility checking ?
| In the event of a mismatch in any of these checking procedures the call shall be 'rejected' or Low Layer Compatibility Negotiation shall be implemented. In the case of a match then the call shall be established. |
|
|
In the case where a number of applications could accept the call, which one actually establishes the connection ?
| The first matched application to respond to the incoming call and which subsequently demonstrates compliance with the compatibility procedures. |
| In the case of a match the application will send an appropriate message to the API and indicate the B channel protocol to be used for the call. |
|
|
In summary, what are the complete list of parameters which may be involved in local terminal selection ?
These are listed below:
- Called party number information element.
- Bearer Capability Information Element.
- Low Layer Compatibility Information Element.
- High Layer Compatibility Information Element.
- Called party number/subaddress information element.
- Progress Indicator Information Element.
- End point Identifier Information Element.
- Terminal Endpoint Identifier.