• 2.1.1. Physical Layer
• 2.1.2. Data Link Layer (D-channel)
• 2.1.3. Network Layer (D-channel)
• Supplemental Services

2.1. B and D Channel Signaling

Data sent between the BRI/2 and the PBX is transmitted over the "S/T" interface. The way in which this data is transferred is controlled by protocols. Protocols are a set of rules that define the format and timing of data transmission between two devices. BRI protocols conform to the first three layers of the OSI model; physical, data link, and network.

2.1.1. Physical Layer

ITU-T Recommendation I.430 defines the physical layer specification for BRI. The physical layer consists of both the hardware (wiring, termination, etc.) and data transmission method. In BRI, two channels of user data (B channels) and one signaling channel (D channel) are transmitted over a single line (a line consists of two twisted-wire pairs; one for transmit and one for receive). To accommodate this, a technique called framing is used. Digital data is sent in frames and contains information from each of the channels, providing a "snapshot" of the data being transmitted at any given time. BRI uses common channel signaling (CCS). This means that one signaling channel (D channel) carries signaling information for more than one user data channel (B channel). Common channel signaling also allows the transmission of additional information, such as ANI and DNIS digits, over the signaling channel.

For example, in telephony applications, user data is usually digitally encoded voice data (PCM). In file transfer applications, user data is packets of HDLC encoded information. Signaling data carries information such as the current state of the channel (i.e., whether the telephone is on-hook or off-hook). The signaling data also indicates who is calling, what type of call it is (data/voice), and what number was dialed.

The figure below represents one BRI layer 1 frame. Each frame contains 48 bits.

Figure 2. BRI Layer 1 Frame

2.1.2. Data Link Layer (D-channel)

The data link layer is where reliable communication between the two physically connected devices takes place. Protocols at this layer deal with setup, maintenance, and disconnection. ITU-T Recommendation Q.920 (ETS 300 125) and Q.921 (LAPD) define the D channel data link layer specification for BRI. LAPD transmits a stream of bits in a defined structure (frame), refer to Figure 3. BRI Layer 2 Frame (D Channel). The receiver interprets the frame. The purpose of the LAPD protocol is to prepare and transmit information between layer 3 entities.

Figure 3. BRI Layer 2 Frame (D Channel)

The Control bits determine the type of frame being sent (information, supervisory, or unnumbered). Information frames are used to transfer data in sequentially numbered frames containing data from the Network layer (layer 3).

2.1.3. Network Layer (D-channel)

ITU-T Recommendation Q.931 (ETS 300 102-1) is a layer 3 ISDN protocol. This protocol deals with signaling procedures, call control, and access to and control of supplemental services. Setting up calls, providing call maintenance, and terminating the call are handled by the exchange of a series of messages between the BRI/2 and the switch. These messages are carried in LAPD frames (see Figure 4).

Figure 4. BRI Layer 3 Frame (D Channel)

The message format comprises variable length fields with the following general format:

• Protocol Discriminator
• Call Reference Value
• Message Type
• Information Elements

The Protocol Discriminator identifies the protocol type used to handle layer three messages. The Call Reference Value is a value assigned to a call for its duration. It has local significance (i.e., it applies to layer 3 messages which are employed between the user and network at either the originating or the terminating end). The Message Type is the set of messages used for establishing, controlling and tearing down a call. Information Elements are used with the message to provide additional information on the type and requirements of the call and are determined by the application to be supported by the connection.

Supplemental Services

Using ISDN API functions, the BRI/2 can perform the following Supplemental Services:

• Called/Calling Party Identification
• Subaddressing
• Hold/Retrieve
• Call Transfer
• Message Waiting

Call Hold and Retrieve are invoked using the following functions:

• cc_HoldAck( )
• cc_HoldCall( )
• cc_HoldRej( )
• cc_RetrieveAck( )
• cc_RetrieveCall( )
• cc_RetrieveRej( )

The other Supplementary Services are typically invoked by sending information from the BRI/2 to the PBX using an appropriate API function. This information is sent as the part of the layer 3 frame called the Information Element (refer to Figure 4). In order for the PBX to interpret the Information Elements as Supplementary Service requests, the Information Elements must be sent as Facility Messages.

The following functions can be used to send Facility Messages:

• cc_SndMsg( ) - Sends a call state associated message to the PBX.
• cc_SndNonCallMsg( ) - Sends a non-call state related messages to the PBX. This function does not require a call reference value.
• cc_SetInfoElem( ) - Sets an information element (IE) allowing the application to include application-specific ISDN information elements in the next outgoing message.

The following functions are used to retrieve Facility Messages:

• cc_GetCallInfo( ) - Retrieves the information elements associated with the CRN.
• cc_GetNonCallMsg( ) - Retrieves a non-call state related ISDN messages to the PBX.

The cc_SndMsg( ) and cc_SndNonCallMsg( ) functions are used to send Facility Messages or Notify Messages to the PBX. The Facility Message (as defined in ETS 300-196-1) is composed of the following elements (see also Figure 5):

• Protocol discriminator
• Call reference
• Message type
• Facility Information Element

The Supplementary Service to be invoked and its associated parameters are specified in the Information Element. This information is PBX-specific and should be provided by the PBX manufacturer. Facility Messages are sent using the cc_SndMsg( ) or cc_SndNonCallMsg( ) function with msg_type = SndMsg_Facility. These functions format the Facility Message (inserting the protocol discriminator, call reference value [only for cc_SndMsg( )] , and message type elements), adds the Information Element data (stored in an application buffer) and sends all the information to the PBX. The PBX, in turn, interprets and acts on the information, and sends a reply to the BRI/2.

As an example, to invoke Supplementary Service `X', you could use the cc_SndMsg( ) function with msg_type = SndMsg_Facility. The Information Element would be defined in a data structure as follows:

ieblk.length = 11;  
ieblk.data[0]  = 0x1c;  /* IE Identifier */  
ieblk.data[1]  = 0x09;  /* Length of information */  
ieblk.data[2]  = 0x91;  /* Protocol Profile */  
/* information */  
ieblk.data[3]  = 0xa1;  /* Component Type */  
ieblk.data[4]  = 0x06;  /* Component Length */  
ieblk.data[5]  = 0x02;  /* invoke tag id */  
ieblk.data[6]  = 0x01;  /* invode tag length */  
ieblk.data[7]  = 0x00;  /* invoke id */  
ieblk.data[8]  = 0x02;  /* operation tag */  
ieblk.data[9]  = 0x01;  /* operation length */  
ieblk.data[10] = 0x06;  /* operation */

NOTE:

The information included in the Information Element is determined by the Supplementary Service being invoked.

The data sent to the switch would be formatted as follows:

Figure 5. Information Element Format

Information elements can also be sent using the cc_SetInfoElem( ) function, which allows the BRI/2 to send application-specific information elements in the next outgoing message. This function is used for rapid deployment of an application that "interworks" with the PBX. A typical application is user-to-user information elements in each outgoing message. This function must be used immediately before calling a function that sends an ISDN message. The information elements specified by this function are applicable only to the next outgoing ISDN message.

When a Supplementary Service is invoked, the network may return a NOTIFY Message to the user. This message can be retrieved using the cc_GetCallInfo( ) function.

The Notify Message (as defined in ETS 300-196-1) is composed of the following elements:

• Protocol discriminator
• Call reference
• Message type
• Notification Indicator

The Notify message is coded as follows:

8	7	6	5	4	3	2	1
x	x	x	x	x	x	x	x
Protocol discriminator
x	x	x	x	x	x	x	x
Call reference
x	x	x	x	x	x	x	x
Message Type
0	0	1	0	0	1	1	1
	Notification Indicator Information element identifier
0	0	0	0	1	0	0	1
Length of Notification Indicator contents
1/1	x	x	x	x	x	x	x
ext.	Notification Description
0	x	x	x	x	x	x	x
ext.	Notification Description
1	0	1	0	0	0	0	1
Notification Data Structure

Coding requirements for other supported Supplementary Services are listed in Table 4.

Table 4. ETSI Specification Cross-Reference for Supplementary Services

Supplementary Service/Description	ETS 300 Specification
Explicit Call Transfer - enables a user (user A) to transform two of that user's calls (an active call and a held call), each of which can be an incoming call or an outgoing call, into a new call between user B and user C. "Call Transferred Alerting" and "Call Transferred Active" messages are returned by the network to the user.	367/369/369
Call Hold/ Retrieve - allows a user to interrupt communications on an existing call and then subsequently, if desired, re-establish communications. When on Hold, the user may retrieve that call from hold, originate a new call, retrieve another call, or establish connection to an incoming call, e.g. a waiting call. Send a facility message with the message type data set to	139/140/141
Subaddressing (allows direct connection to individual extensions or devices sharing the same phone number, or, as a proprietary messaging mechanism). Provides additional addressing above the ISDN number of the called user.	059/060/061
Called/Calling Party Identification CLIP - Provides the calling user's ISDN number and subaddress information to the called user. This information is sent in the "Setup message" (see ETS300 102-1) by the calling user to the switch, and from the switch to the called user.	089/091/092
Called/Calling Party Identification CLIR - Restricts presentation of the calling user's ISDN number to the called user.	090/091/093
Called/Calling Party Identification COLP - Provides the calling user's ISDN number to the called user.	094/096/097
Called/Calling Party Identification COLR - restricts the ISDN and the subaddress of the called user.	095/096/098
Advice of Charge - S	178/181/182
Advice of Charge - D	179/181/182
Message Waiting Indication	650/745-1/356-20

Click here to contact Dialogic Customer Engineering