03 2430eu01al 01 Signaling Management

Signaling Management Siemens
Signaling Management
Contents
1 Congestion Management 3
2 PVC Status Management 11
3 Switched Virtual Circuits (SVC) Fehler! Textmarke nicht definiert.
TI2430EU01AL-01
1
Siemens Signaling Management
2 TI2430EU01AL-01
1 Congestion Management
Fig. 1
TI2430EU01AL-01
3
General
The chief objective of Congestion Management is to maintain the specified grade of
service (e.g., throughput, delay, frame loss) in the virtual circuits.
Congestion Management contains functions for avoiding congestion (Congestion
Avoidance). In other words, congestion should be prevented from ever occurring.
There are also functions for recovering from existing congestion situations
(Congestion Recovery) and for detecting congestion.
The congestion functions have the following objectives:
To minimize the number of frames discarded
To keep the degradation in service quality during congestion to a minimum
To be easy to implement and to produce only a minor amount of additional load
To equally distribute the resources (memory, bandwidth, processing capacity)
between the virtual circuits
To prevent congestion from spreading to other network elements
To optimize the utilization of the existing network resources
To effectively function regardless of the direction the traffic is flowing.
The effects of congestion on the service quality is defined by two points. If the traffic
exceeds the point A (see diagrams), the delay increases overproportionally. The
network element is in a so-called mild congestion state; the quality of the service
decreases with increasing traffic volume. From point B the network begins to manage
the congestion by discarding frames in order to prevent further degradation in service
quality. The network element is in the severe congestion state.
Points A and B can usually be defined for specific networks or network elements by
setting threshold values. In this way the service quality can be manipulated.
4 TI2430EU01AL-01
Network
Throughput
No congestion Mild Severe
within network congestion congestion
Region 1 Region 2 Region 3
Congestion Congestion Offered load

Avoidance Recovery
Fig. 2
No congestion Mild Severe

within network congestion congestion
Delay Region 1 Region 2 Region 3
Congestion Congestion Offered load

Avoidance Recovery
Fig. 3
TI2430EU01AL-01
5
Explicit Congestion Notification

Most end-to-end communication protocols can control their transmission rates either
directly at the source of information (source-controlled) or indirectly using the
destination of the information (destination-controlled). Frame Relay provides explicit
congestion notification.
Explicit Congestion Management:

allows the end users to be notified that mild congestion is being experienced in the
network
does not discard frames
is used if the specified threshold value for mild congestion has been exceeded in a
buffer area of a network element
Explicit Congestion Management sets the FECN (Forward Explicit Congestion
Notification) and BECN (Backward Explicit Congestion Notification) bits. This takes
place in the network element in which the congestion occurred.
End devices that detect the set BECN and/or FECN bits can then reduce their
transmission rate to counteract the effects of the congestion.
FECN:
If mild congestion occurs in a transmission buffer assigned to a transmission channel,
the FECN bit is set to 1 in the header of the frames for transmission in all virtual
circuits. This enables destination-controlled communication protocols to reduce the
transmission rate.
BECN:
If mild congestion occurs in a transmission buffer assigned to a transmission channel,
the BECN bit is set to 1 in the header of the frames for transmission in all virtual
circuits. This enables source-controlled communication protocols to reduce the
transmission rate.
CLLM:
CLLM (Consolidated Link Layer Management) is an alternative to using the FECN
and BECN bits. If congestion is detected in a network element, a special message is
sent backward in a separate virtual circuit to notify the preceding network elements of
the congestion. This has the advantage that frames flowing in the backward direction
are not necessary to indicate congestion.
6 TI2430EU01AL-01
Uncongested
ACT SCT MCT Empty

Channel 1 Transmission buffer Channel 5
FECN 0 of channel 1 FECN 0
BECN 0 BECN 0
ACT SCT MCT Empty
Trans. buffer of
channel 5
Channel 1 Channel 5
Mildly congested
ACT SCT MCT Empty

Frame Relay Channel 1 Transmission buffer Channel 5
network node FECN 0 of channel 1 FECN 1
BECN 1 BECN 0
ACT SCT MCT Empty
Trans. buffer of
channel 5
Severely congested
ACT SCT MCT Empty

Channel 1 Transmission buffer Channel 5
FECN 1 of channel 1 FECN 1
BECN 1 BECN 1
ACT SCT MCT Empty
Trans. buffer of
channel 5
Fig. 4
TI2430EU01AL-01
7
Implicit Congestion Management:

End devices can detect congestion in a network even without explicit notification – for
example, if the number of packets not received exceeds a specified threshold. The
end devices must also ensure that the transmission rate is reduced in order to
counteract the effects of the congestion.
Implicit Congestion Management
allows the end users to be implicitly notified that severe congestion has occurred
in the network
discards (specific) frames
is used whenever the specified threshold value for severe congestion in a buffer
area of a network element has been exceeded or if the buffer overflows (absolute
congestion).
The FECN and BECN bits are set both for mild as well as severe congestion.
Discard Eligibility
The use of the DE bit by end devices or the network is optional. If the DE bit is set in
a header of a frame, the frame is preferentially discarded during severe congestion.
This applies to frames that have recently been written to the transmission buffer as
well as to buffered frames that have not yet been sent. Consequently, frames sent at
rates above the Committed Information Rate (CIR) – i.e., at the Excess Information
Rate (EIR), are preferentially discarded. The grade of service is not impaired as a
consequence.
8 TI2430EU01AL-01
Channel 1
Severely congested
ACT SCT MCT Empty

Frame Relay
network node Channel 1 Transmission buffer Channel 5
FECN 1 for channel 1 FECN 1
BECN 1 BECN 1
ACT SCT MCT Empty
Transmission buffer
for channel 5
Selective discarding of
frames naving the DE bit set.
Fig. 5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TI2430EU01AL-01
9
10 TI2430EU01AL-01
2 PVC Status Management
Annex D
Annex A
LMI
Fig. 6
TI2430EU01AL-01
11
General
The procedures of the PVC Status Management at the user-to-network interface
(UNI) and network-to-network interface (NNI) enable the following:
Link integrity verification between the user and network or between networks
Notification of the user or network node if a new PVC has been switched
Detection by the user or network node that an existing PVC has been canceled
Transmission of status information on existing PVCs to users or network nodes
There are three slightly different standards for the PVC Status Management:
ITU-T: Q.933 Annex A (uses DLCI 0; can be used at the UNI or NNI)
ANSI: T1.617 Annex D (uses DLCI 0; can be used at the UNI or NNI)
Industrial standard: LMI (uses DLCI 1023; can only be used at the UNI)
The procedures for all three standards of the PVC Status Management are based on
the replacement of the following message types between the user and network:
Status enquiry
Status
Single PVC asynchronous status
Status enquiry and status messages

"Status Enquiry" and "Status" messages are synchronous handshaking messages for
ensuring the connection between the two interfaces of the access channel. At the
UNI, a Status Enquiry message is sent in the direction of the network from the user
side. The network side replies with a Status message.
At the interfaces between networks (NNI), a Status Enquiry message is sent from
both sides and the two sides reply with a Status message (bi-directional procedures
can also be optionally used at the UNI – for example, when connecting a private FR
network to a public FR network).
Status Enquiry messages always have the same format.
Status messages can have two different formats:
A "Keep Alive" signal that verifies the connection at the access channel
A "Full Status" signal that indicates the status of all virtual circuits in the access
channel.
The Status Enquiry signal indicates whether a "Keep Alive" or a "Full Status" signal is
requested.
12 TI2430EU01AL-01
Q.933 Annex A
T1.617 Annex D
LMI
Network Frame Relay

User
network
Status Port
CPE
UNI
FR network node
Status Enquiry
FR network access node

or
FR customer premises equipment
Fig. 7
Q.933 Annex A bidirectional

T1.617 Annex D bidirectional
User+ User+
Network Network
Frame Relay Status Frame Relay

network network
Port Status Enquiry Port
NNI
Status Enquiry
FR network node FR network node
Status
Fig. 8
TI2430EU01AL-01
13
Single PVC Asynchronous Status message

This message type is automatically sent without solicitation by the network side at the
UNI and NNI whenever the status of a PVC changes (active to inactive or vice versa)
or whenever a PVC is canceled. If the status of more than one PVC changes, the
message is sent separately for each relevant PVC.
Single PVC Asynchronous Status messages have no effect on Status Enquiry and
Status messages.
TIP:
The use and implementation of this message type are optional in the case of the
Annex A and Annex D protocols. Network nodes using the LMI protocol in the access
channel at the UNI have to be set to "LMI Extended" in order to support Single PVC
Asynchronous messages. This message type is known in the LMI protocol as an
Update Status message.
System parameters
The accepted value ranges for the configurable parameters are shown in the tables
below. The parameters themselves are explained later.
Counter Description Range Default

N391 Full Status Polling Counter 1-255 6
N392 Error Threshold 1-10 3
N393 Monitored Events Count 1-10 4
N392 must be less than or equal to N393
N391 is always assigned to the user side. N391 is assigned to the user and network
sides if the bi-directional procedures are used.
Timer Description Range Default

T391 Link Integrity Verification Polling Timer 5-30 10
T392 Polling Verification Timer 5-30 15
T392 should be longer than T391
T391 is always assigned to the user side. T391 is assigned to the user and network
sides if the bi-directional procedures are used.
T392 is always assigned to the network side. T392 is assigned to the user and
network sides if the bi-directional procedures are used.
14 TI2430EU01AL-01
Status Enquiry Message

Control Field 03 Unnumbered Information Frame /P=0
Protocol Discriminator 08 Annex A (09 bei LMI)
Call Reference 00
Message Type 75 Status Enquiry
Locking Shift * Nur bei Annex D unterstützt
Identifier 51 Report (01 bei LMI)
Length 01
Report Type 00=Full Status/01=Link Integrity Verification
Identifier 53 Sequence Numbers (03 bei LMI)
Length 02
Current Sequence Nr. 01-FF
Last Received Seq. Nr. 01-FF
Status Message
Call Reference 00
Message Type 7D Status Enquiry
Length 01
Report Type 01 Link Integrity Verification only
Length 02
TI2430EU01AL-01
15
Full Status Message

Call Reference 00
Message Type 7D Status Enquiry
Length 01
Report Type 00 Full Status (für alle PVC)
Length 02
Identifier 57 PVC Status (7 bei LMI)
Length 03-06
DLCI (msb) 00XXXXXX Most 6 significant bits
DLCI (Isb) 1XXXX000 Least 4 significant bits
Status 1000NDAR New/Delete/Active/RNR
CIR (msb) RNR (Receive Not Ready) und CIR Felder werden bei
CIR
Annex A und Annex D nicht unterstützt
CIR (Isb)
16 TI2430EU01AL-01
Single PVC Asynchronous Status Message

Call Reference 00
Message Type 7D Status
Locking Shift Nur bei Annex D unterstützt
Identifier 51 Report (7B Update Status bei LMI ext.)
Length * 01 * nur bei Annex A und Annex D
Report Type * 02 Single PVC Asynchronous Status
Identifier 57 PVC Status (7 bei LMI ext.)
Length 03-06
DLCI (msb) 00XXXXXX Most 6 significant bits
DLCI (Isb) 1XXXX000 Least 4 significant bits
Status 1000NDAR New/Delete/Active/RNR
CIR (msb) RNR (Receive Not Ready) und CIR Felder werden bei
CIR
Annex A und Annex D nicht unterstützt
CIR (Isb)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TI2430EU01AL-01
17
Procedures
The PVC Management procedures use periodic polling to determine the status of the
permanent virtual circuits and to check whether the access channel is intact (link
integrity verification).
Periodic polling
The user side begins with the polling as described below.
1. The customer premises equipment sends a Status Enquiry message every T391
seconds in the direction of the network and resets its polling timer (T391). The
T391 interval between the transmitted messages is known as the polling interval.
2. Generally a Status Enquiry message initiates only a link integrity verification. The
status of all PVCs is polled only every N391 polling cycles.
3. The network side replies to each Status Enquiry message with a Status message
and resets the timer T392 used for error detection. If the Status Enquiry message
contains a status request for all PVCs, the network side has to reply with a Status
message marked as a Full Status report. Each Status message sent in reply to a
Status Enquiry message contains the "Link Integrity Verification" and "Report
Type" information elements. If the status of all PVCs has been polled, the Status
message must also include a "PVC Status" element for each PVC that is
configured in the access channel.
4. The customer premises equipment interprets the Status message in accordance
with the contents of the "Report Type" information element. The network side can
namely reply to each enquiry with a "Full Status" report if the status of a PVC has
changed or if a new PVC has been configured. If a "Full Status" message has
been received, the customer premises equipment has to update the status of all
PVCs.
5. If a previous PVC is no longer included in a "Full Status" message, the customer
premises equipment interprets this as meaning that the PVC is no longer
available in the access channel.
TIP
The optional "Single PVC Asynchronous Status" message is not part of the periodic
polling process.
18 TI2430EU01AL-01
FR network access node Frame Relay

or network
Port
CPE
UNI
FR network node
Status Enquiry (5,4)
T391 Status (5,5)
Status Enquiry (6,5) T 392
Status (6,6)
T391
Status Enquiry (7,6) T 392
Status (7,7)
T391
Fig. 9
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TI2430EU01AL-01
19
Link Integrity Verification

The purpose of the "Link Integrity Verification" information element is to monitor the
status in the DLCI 0 (or 1023). The monitoring is necessary because the PVC
Management procedures work with unnumbered information (UI) frames at level 2.
Message loss can still be detected with this method.
The user and network sides have two internal counters used as follows:
A Send Sequence Counter containing the value of the send sequence number
field sent with the previous "Link Integrity Verification" information element.
A Receive Sequence Counter containing the value of the previously received send
sequence number field for entry in the next "Link Integrity Verification" information
element for sending in the receive sequence number field.
The following procedure is used for link integrity verification:

1. Before a message is exchanged, the user and network sides reset their send and
receive sequence counters to zero.
2. Each time the customer premises equipment sends a Status Enquiry message, it
increases the value of the send sequence counter in increments of one and enter
the value in the send sequence number field. The current value of the receive
sequence counter is likewise entered in the receive sequence number field. The
customer premises equipment increases the send sequence counter modulo
256. The value zero is omitted.
3. If the network side receives a Status Enquiry message, it compares the received
receive sequence number with the current value in its own send sequence
counter. The user side has received all of the messages if the values are
identical. The received send sequence number is stored in its own receive
sequence counter. The network side then increases the send sequence counter
by one and enters this value in the send sequence number field and the value of
the receive sequence counter (with the last send sequence number received) in
the receive sequence number field of the information element to be sent. In
conclusion, the full Status message is sent to the customer premises equipment.
The network side increases the send sequence counter modulo 256. The value
zero is omitted.
4. When the user side receives a Status message, it compares the received receive
sequence number with the current value in its own send sequence counter. The
network side has received all of the messages if the values are identical. The
received send sequence number is stored in its own receive sequence counter.
20 TI2430EU01AL-01

or network
Port
CPE
UNI
FR network node
Send Sequence Counters

Current=0 Current=0
Last=0 Last=0 Receive Sequence Counters
Fig. 10

or network
Port
UNI
CPE
Status Enquiry FR network node
Current=1
Last=0
Current=1 Current=0
Receive Sequence Counters
Last=0 Last=0
Fig. 11
TI2430EU01AL-01
21
Reporting new PVCs

One of the functions of periodic polling is to notify the user side whenever new PVCs
have been connected. A "Full Status" message is used for this purpose. This method
ensures that an existing PVC cannot simply be canceled and a new PVC connected
under the same DLCI without notifying the user side. The PVC reporting function is
implemented as follows:
1. Whenever a new PVC has been connected, the network side sets the "New" bit
in the "PVC Status" information element for the associated PVC to 1 in the "Full
Status" message.
2. The network side keeps the "New" bit set until the user side has confirmed the
reception of the message with a Status Enquiry message with the relevant
"Receive Sequence Number".
3. If the user side receives a Full Status message in which a "PVC Status"
information element has set the "New" bit for an as yet unknown DLCI, the
customer premises equipment marks the PVC as new and includes it in the list of
existing PVCs.
TIP
The report procedures for new PVCs are not supported by "Single Asynchronous
Status" messages.
Reporting PVC availability

The user side also uses the "PVC Status" message to detect changes in the status of
configured PVCs. The user side requests the full status of all PVCs every N391
polling intervals. The network side replies with a Status message containing a "PVC
Status" information element for each configured PVC in the access channel. Each
PVC Status information element has an "Active" bit to indicate the (un)availability of
the PVC.
If a PVC is reported to the user side as being unavailable, no more frames are sent in
that PVC. Frames can only be sent in the direction of the network side when the PVC
is reported to be available again.
TIP
The "Active" bit and "New" bit are fully independent of each other. For example, a
new PVC marked as inactive can be shown in a Status message.
22 TI2430EU01AL-01

or network
Port
UNI
CPE
Status Enquiry FR network node
Current=1
Last=0
Current=1 Current=0
Last=0 Last=1
Fig. 12

or network
Port
UNI
CPE
Status FR network node
Current=1
Last=1
Current=1 Current=1
Last=0 Last=1
Fig. 13
TI2430EU01AL-01
23
Error states
The customer premises equipment as well as the Frame Relay network use polling
for error monitoring. The following errors can be generally detected:
In-channel signaling link (DLCI 0/1023) reliability errors (e.g., non-receipt of
Status/Status Enquiry messages or invalid sequence numbers in the Link Integrity
Verification information element).
Protocol errors in the signaling link. Messages with protocol errors are completely
ignored.
Both sides can respond to level 1 errors as well as to frame errors (e.g., an invalid
frame sequence checksum).
Error detection on the network side

The network side sets the "Active" bit to 0 if a fault in the PVC has been detected in
the network.
The network side increases an error counter in increments whenever any of the
following conditions is encountered:
A "Status Enquiry" message was not received before the T392 timer expired. T392
is restarted as a consequence.
Invalid contents in the Link Integrity Verification information element (invalid
receive sequence number). The receive sequence number received is invalid if it
is not identical to the last send sequence number sent.
Error detection in the customer premises equipment

The user side increases an error counter in increments whenever any of the following
conditions is encountered:
If only a Link Integrity Verification message is received instead of a requested Full
Status message, it is discarded. The error counter is increased by an increment of
one when the T391 timer expires.
If a Status message that was not requested is received, it is ignored and the error
counter is increased by an increment of one.
If no message is received during the polling interval T391 after a Status message
has been requested. On expiry of T391 the error counter is increased.
Invalid contents in the Link Integrity Verification information element (invalid
receive sequence number). The receive sequence number received is invalid if it
is not identical to the last send sequence number sent.
24 TI2430EU01AL-01
FR network acces node Frame Relay

or network
Port
UNI
CPE
Status FR network node
Current=1
Last=1
Current=1 Current=1
Last=1 Last=1
Fig. 14
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TI2430EU01AL-01
25
If the polling detects a situation that is impairing the service, the user side
discontinues sending frames in the PVCs in the access channel. Polling remains
active in order to determine when the service can be continued – in other words,
when the error situation has been rectified.
One option of detecting a situation that is adverse to the service is to detect N392
errors in N393 polling cycles.
In the opposite direction, the customer premises equipment has the option of
restarting the service in the access channel if N392 polling cycles are completed
without errors. The user side can then send frames in the active PVC in the access
channel again.
Maximum number of PVCs and maximum frame length

The maximum frame length (N203) is a configurable parameter. You must consider
two major requirements when setting the parameter:
Maximum length of the frames sent by the customer premises equipment
Maximum length of the Frame Relay messages (PVC Management, SVC
signaling)
You should not configure the maximum frame length to the maximum possible frame
length, rather to the actual length required. However, the configured maximum frame
length must allow "Full Status" messages to be sent. The following formula is useful
for calculating the maximum frame length:
N203 = Status overhead (bytes) + (# of bytes per PVC x # of PVCs)
where:
Status overhead = 11 bytes (LMI and Annex A) or 12 bytes (Annex D)
# of bytes per PVC = 8 (LMI) or 5 (Annex A and Annex D)
The maximum number of PVCs in the access channel can be calculated as follows:
Max. # of PVCs = (N203 - status overhead) / # of bytes per PVC
where:
Status overhead = 11 bytes (LMI and Annex A) or 12 bytes (Annex D)
# of bytes per PVC = 8 (LMI) or 5 (Annex A and Annex D)
For a maximum frame length of 1600 bytes, the maximum number of PVCs is:
for LMI: 198
for Annex A: 317
for Annex D: 317
26 TI2430EU01AL-01
Control Field 1 byte

Protocol Discriminator 1 byte
1 byte
Call Reference
1 byte
Message Type
3 bytes
Report Example 1:
Calculation of the maximum
4 bytes frame length for 100 configured
PVCs and Annex A
Sequence Numbers N203 = 11 bytes + (5 bytes * 100) = 511 bytes
5 bytes
PVC Status 1 Example 2:

Calculation of the maximum number of PVCs
for a maximum frame length of
. 4472 bytes and Annex A.
. 5 bytes
. Max # of PVCs = (4472 - 11) / 5 = 892 PVCs
PVC Status N
Fig. 15
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TI2430EU01AL-01
27
28 TI2430EU01AL-01
3 Switched Virtual Circuits (SVC’s)
FRF.4/
X.36
CPE
FRF.10/
X.76
FRF.4/
X.36
CPE
FRF.4/
X.36 CPE
Fig. 16
TI2430EU01AL-01
29
General
Where required, switched virtual connections can be set up with the aid of SVC
signaling via a frame relay network. The signaling procedures eliminate the
configuration work required for switching PVCs, and it is the signaling software that
must be implemented in terminal equipment and exchanges that is the complex part.
In the past, the implementation of frame relay SVCs was never really an issue for
device manufacturers and network operators, precisely because of this complexity.
Frame Relay PVC services could be sold at a good price, as this solution is
considerably cheaper than dedicated lines.
Nonetheless, there are also arguments today increasingly in favor of implementing
SVC services. Just as the size of Frame Relay networks is constantly increasing, so
too is the expenditure required for the administration and configuration of the many
PVCs. Network operators can reduce their administration costs by implementing
SVCs within their networks. They can still offer PVCs at the FR-UNI, but map them
internally within the network to SVCs. This mapping is known as “soft PVCs”
(SPVCs).
There are several protocols for the dynamic setup and release of virtual connections
in Frame Relay networks, which are set out in different standards. Frame Relay
SVCs via UNI and NNI however always use procedures based on the ITU-T Q.933
standard. The Q.933 messages exchanged to set up and release calls use the error-
protected Q.922 data link protocol at the DLCI 0.
The following protocols are employed at the subscriber interface:
FRF.4: Frame Relay UNI SVC IA: The Frame Relay Forum has defined a subset
of the ITU-T Q.933 specification for use at the UNI interface. The objective of this
variant is to achieve the easiest possible implementation to allow its early
application. Only case A of the ISDN application is covered and the number of
message types and information elements is limited to a minimum.
ITU-T X.36 Amendment 1: switched virtual circuit (SVC) signaling at the
DTE/DCE interface: here, the ITU-T has defined procedures for FR signaling at
the DTE/DCE interface of a public Frame Relay network. These procedures are
based on the FRF.4 specification but contain circuits for facilities such as reverse
charging, closed user groups etc.
ITU-T Q.933: Integrated Services Digital Network (ISDN) Digital Subscriber
Signaling System No.1 (DSS 1) - signaling specifications for frame mode switched
and permanent virtual connection control and status monitoring.
30 TI2430EU01AL-01
FR Netzzugangsknoten
oder ITU-T X.36
FR Teilnehmerendgerät FRF.4
Frame Relay
DTE DCE
Netz
Port
CPE
UNI
FR Netzknoten
SVC Signalisierungsnachrichten zum DCE
SVC Signalisierung SVC Signalisierung

SVC Signalisierungs-
nachrichten zum DTE
LAPF Rahmen
LAPF LAPF
auf DLCI = 0
Physical Layer Physical Layer
Fig. 17
Legend:
FR network access node or FR terminal equipment, Frame Relay network, FR network node, SVC
signaling messages to the DCE, SVC signaling, SVC signaling messages to the DTE, LAPF frame set
to DLCI = 0
TI2430EU01AL-01
31
The following protocols are used at the network interface:

FRF.10: Frame Relay Network-to-Network SVC Implementation Agreement
ITU-T X.76 Amendment 1: Network-to-Network Interface between Public Data
Networks providing the Frame Relay Data Transmission Service, SVC part.
There are two numbering plans for Frame Relay SVCs:
E.164 ISDN numbering plan
X.121 International Numbering Plan for Public Data Networks
The use of a specific numbering plan is not forcibly prescribed, but the E.164
numbering plan is preferred for the long term, however.
32 TI2430EU01AL-01
Forward direction
Backward direction
ITU-T X.76
FRF.10
UNI NNI NNI UNI
Originating Transit Terminating

CPE Network CPE
Network Network
Calling User Called User

Calling Called Calling Called
STE STE STE STE
SVC signaling
SVC signaling SVC signaling
Messages
LAPF frames
LAPF LAPF
on DLCI = 0
Physical Layer Physical Layer
Fig. 18
Legend:
Forward direction, Backward direction, SVC signaling, LAPF frame set to DLCI = 0
TI2430EU01AL-01
33
3.1 Frame Relay in the ISDN Network

ITU-T recommendation Q.933 defines the FR SVC signaling procedures in an ISDN
network. Two cases are described:
Case A: In this case, the local exchange does not provide any Frame Relay
functions. For this reason, mechanisms are required to gain access to a Frame
Relay exchange that can be located either inside or outside the ISDN network. For
example, access to the Frame Relay exchange can be provided via ISDN
signaling or a private line. The SVC signaling protocol can now run on this and be
used to set up Frame Relay connections when required.
Case B: In this case, the local exchange already provides the Frame Relay
functions.
34 TI2430EU01AL-01
ISDN Frame Relay
SIEMENS SIEMENS
NIXDORF NI XDORF
Lokale FR
Vst. Vst.
Q.931
Q.933
Fig. 19
Legend: Local exchange, FR exchange
ISDN
Lokale
Vst. +
FR
SIEMENS SIEMENS
NIXDORF NIXDORF
Vst.
Q.933
Fig. 20
Legend: Local exchange + FR exchange
TI2430EU01AL-01
35
UNI signaling
The calling party sends out a SETUP message to set up a new connection. This
message basically contains the following information:
Called party address: specifies an address in a standardized numbering plan
such as E.164 or X.121.
Link Layer Core Parameter : specifies parameters including throughput,
maximum frame size, burst size, etc. which are used by the network to allocate
resources for the required connection.
End-to-End Parameter: these parameters are optional and specify parameters
which are only relevant for communication between the terminal equipment, such
as window size and the end-to-end application protocol, for example. These
parameters are transmitted transparently through the network.
Additional Parameter: specifies additional parameters such as the calling party
address, transit network selection, etc.
The SETUP message passes through the network to the called party. The routing is
either predetermined by the static configuration of the network node, or the network
nodes communicate with one another using a dynamic routing protocol to find
possible routes. All nodes along the route taken by the call check whether they can
provide enough resources to set up the required connection without impairing
existing connections. Should there be any problems with this or the called party, the
call is rejected by returning a RELEASE COMPLETE message.
If the call is accepted by the called party, the latter returns a CONNECT message to
the calling party. This message establishes the end-to-end connection and the DLCIs
are also allocated step-by-step for this connection.
Between the SETUP and CONNECT messages, other messages can be sent to
show the progress of the call. A CALL PROCEEDING message shows that the
recipient of the SETUP message has received the message and is processing it. A
CONNECT ACKNOWLEDGE message can be returned as a confirmation of receipt
of a CONNECT message.
The calling party, the called party or a network element involved in the call can
release the connection by sending out a DISCONNECT message. The other side
responds with a RELEASE message. This message is confirmed step-by-step with a
RELEASE COMPLETE message.
36 TI2430EU01AL-01
Calling Called
DTE DCE DCE DTE
ITU-T X.36 ITU-T X.36

FRF.4 FRF.4
Frame Relay
CPE CPE
Netz
UNI UNI
Null
SET Null
UP
Call Call
ING Initiated Null
Initiated
PROCED
CALL SET
UP Null
Outgoing
Call Call Call
Proceeding Present D I NG Present
LL PROCE
Outgoing CA Incoming
Incoming N NECT Call
Call Call CO
Proceeding Proceeding
Proceeding
ECT
CONN Active Active
Active
Active
Fig. 21
Legend: Frame Relay network, Zero, CALL PROCEEDING
TI2430EU01AL-01
37
Calling Called
DTE DCE DCE DTE
ITU-T X.36 ITU-T X.36

FRF.4 FRF.4
Frame Relay
CPE CPE
Netz
UNI UNI
Active DISC Active
O NNE
CT Active
Active
Disconnect
Request ASE
RELE DISC
Disconnect O NNE
Request CT
Disconnect
RELE
A
COM SE
Indication ASE
PLET RELE Disconnect
E
Indication
Null RELE
A
Null COM SE Null
PLET
Null E
Fig. 22
Legend: Frame Relay network, Zero
38 TI2430EU01AL-01
3.2 NNI Signaling

ITU T (X.76) Amendment 1
This ITU standard specifies the procedures for Frame Relay SVC signaling at the
DCE-DCE interface of Frame Relay data networks. The protocol is similar to the X.36
protocol, but contains additional procedures for managing connections between
several networks.
Frame Relay Forum Variant (FRF.10)

The Frame Relay Forum has defined a subset of the ITU-T X.76 specification for use
at the NNI interface. The objective of this variant is to achieve the easiest possible
implementation to allow early application in networks. This way, for example, the
additional facilities of X.76 signaling, such as transit network identification, call
identification, closed user group interlock code, reverse charging indication, etc. are
not supported.
TI2430EU01AL-01
39
ITU-T X.76
FRF.10
UNI NNI UNI
Originating Terminating
CPE CPE
Network Network
Calling Called
STE STE
Null
SETU Null
P
Call Call
NG Initiated
Present CEDI
CAL L PRO
Call
Proceeding
Sent
Call
Proceeding
Received
ECT
CONN
Active
Active
Fig. 23
Legend: Zero
40 TI2430EU01AL-01
ITU-T X.76
FRF.10
UNI NNI UNI
Originating Terminating
CPE Network CPE
Network
Calling Called
STE STE
Active
REL Active
EAS
E
Release
Release
LETE indication
Request
E CO MP
AS
RELE
Null
Null
Fig. 24
Legend: Zero
TI2430EU01AL-01
41
42 TI2430EU01AL-01
4 Exercises
TI2430EU01AL-01
43
44 TI2430EU01AL-01
Exercise 1
Title: Congestion management
Objectives: The participant is able to explain the mechanisms of
congestion management
Prerequisite: None
Exercise:
Select the correct answers to the following questions.

Test
1. The primary objective of the overload control mechanisms (congestion
management) is to maintain the specified service quality (e.g.: throughput, delay,
frame loss) on the switched virtual channels.
Which of the statements below are correct?
Congestion management includes mechanisms that aid congestion avoidance.
Congestion management includes mechanisms for recovering from existing

overload situations (congestion recovery).
Congestion management includes mechanisms that do not permit existing

congestion to worsen.
2. Which fields does congestion management use in the Frame Relay frame?
DLCI
C/R
EA
FECN
BECN
DE
TI2430EU01AL-01
45
46 TI2430EU01AL-01
Exercise 2
Title: PVC status management
Objectives: The participant is able to name the possible protocols of PVC
status management and explain the fundamental operational
sequences.
Prerequisite: None
Exercise:

Test
1. The procedures of PVC status management at the UNI subscriber interface and
at the network interface enable:
Link integrity verification between the subscriber and the network, or between
networks.
Notification of the subscriber or network node if a new PVC has been switched.
Detection by the subscriber or network node that an existing PVC has been
deleted.
Sending status information on existing PVC's to the subscriber or network node.
Setup and release of soft PVC's.
2. There are three slightly different standards for PVC status management:
ITU-T: Q.933 Annex A (uses DLCI 0, suitable for use at UNI or NNI)
ANSI: Q.617 Annex D (uses DLCI 0, suitable for use at UNI or NNI)
Industry standard: LMI (uses DLCI 1023, suitable for use at UNI or NNI)
Industry standard: LMI (uses DLCI 1023, suitable for use at UNI only)
TI2430EU01AL-01
47
3. The procedures of all three standards of PVC status management are based on
the exchange of the following report types between the subscriber and the
network:
Status Inquiry
Status
Bi-directional Asynchronous Status
Single PVC Asynchronous Status
4. The procedures of PVC management use periodic polling to determine the status
of the permanent virtual channels and to test whether the access channel is
intact (link integrity verification).
The user side starts the polling.
The network side starts the polling.
The user side replies with a status report.
The network side replies with a status report.
48 TI2430EU01AL-01
Exercise 3
Title: Switched virtual circuits
Objectives: The participant is able to give an overview of SVC protocols
Prerequisite: None
Exercise:

Test
in Frame Relay networks, which are set down in various standards. Frame Relay
SVC's via UNI and NNI, however, always use procedures based on the ITU-T Q.933
standard.
The following protocols are used at the subscriber interface:
FRF.10
FRF.4
ITU-T X.36 Amendment 1
ITU-T Q.933
FRF.10
FRF.4
ITU-T Q.933
TI2430EU01AL-01
49
50 TI2430EU01AL-01
5 Solution
TI2430EU01AL-01
51
52 TI2430EU01AL-01
Solution 1
Title: Congestion management
Objectives: The participant is able to explain the mechanisms of
congestion management
Prerequisite: None
Exercise:

Test
1. The primary objective of the overload control mechanisms (congestion
management) is to maintain the specified service quality (e.g.: throughput, delay,
frame loss) on the switched vital channels.
Which of the following statements are correct?
Congestion management includes mechanisms that aid congestion avoidance.
Congestion management includes mechanisms for recovering from existing

overload situations (congestion recovery).
Congestion management includes mechanisms that do not permit existing

congestion to worsen.
2. Which fields does congestion management use in the Frame Relay frame?
DLCI
C/R
EA
FECN
BECN
DE
TI2430EU01AL-01
53
Solution 2
Title: PVC status management
Objectives: The participant is able to name the possible protocols of PVC
status management and explain the fundamental operational
sequences.
Prerequisite: None
Exercise:

Test
1. The procedures of PVC status management at the UNI subscriber interface and
at the network interface enable:
Link integrity verification between the subscriber and the network, or between
networks.
Notification of the subscriber or network node if a new PVC has been switched.
Detection by the subscriber or network node that an existing PVC has been
deleted.
Sending status information on existing PVC's to the subscriber or network node.
Setup and release of soft PVC's.
2. There are three slightly different standards for PVC status management:
ITU-T: Q.933 Annex A (uses DLCI 0, suitable for use at UNI or NNI)
ANSI: Q.617 Annex D (uses DLCI 0, suitable for use at UNI or NNI)
Industry standard: LMI (uses DLCI 1023, suitable for use at UNI or NNI)
Industry standard: LMI (uses DLCI 1023, suitable for use at UNI only)
54 TI2430EU01AL-01
3. The procedures of all three standards of PVC status management are based on
the exchange of the following report types between the subscriber and the
network:
Status Inquiry
Status
Bi-directional Asynchronous Status
Single PVC Asynchronous Status
4. The procedures of PVC management use periodic polling to determine the status
of the permanent virtual channels and to test whether the access channel is
intact (link integrity verification).
The user side starts the polling.
The network side starts the polling.
The user side replies with a status report.
The network side replies with a status report.
TI2430EU01AL-01
55
Solution 3
Title: Switched virtual circuits
Objectives: The participant is able to give an overview of SVC protocols
Prerequisite: None
Exercise:

Test
in Frame Relay networks, which are set down in various standards. Frame Relay
SVC's via UNI and NNI, however, always use procedures based on the ITU-T Q.933
standard.
The following protocols are used at the subscriber interface:
FRF.10
FRF.4
ITU-T Q.933
FRF.10
FRF.4
ITU-T Q.933
56 TI2430EU01AL-01

03 2430eu01al 01 Signaling Management

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

03 2430eu01al 01 Signaling Management

Uploaded by

Copyright:

Available Formats

Signaling Management Siemens

Congestion Congestion Offered load

No congestion Mild Severe

Congestion Congestion Offered load

Explicit Congestion Notification

Explicit Congestion Management:

ACT SCT MCT Empty

ACT SCT MCT Empty

ACT SCT MCT Empty

Implicit Congestion Management:

ACT SCT MCT Empty

2 PVC Status Management

Status enquiry and status messages

Network Frame Relay

FR network access node

Q.933 Annex A bidirectional

Frame Relay Status Frame Relay

Single PVC Asynchronous Status message

Counter Description Range Default

Timer Description Range Default

Status Enquiry Message

Full Status Message

Single PVC Asynchronous Status Message

FR network access node Frame Relay

T391 Status (5,5)

Status Enquiry (6,5) T 392

Status Enquiry (7,6) T 392

Link Integrity Verification

The following procedure is used for link integrity verification:

FR network access node Frame Relay

Send Sequence Counters

Last=0 Last=0 Receive Sequence Counters

FR network access node Frame Relay

Status Enquiry FR network node

Reporting new PVCs

Reporting PVC availability

FR network access node Frame Relay

Status Enquiry FR network node

FR network access node Frame Relay

Status FR network node

Error detection on the network side

Error detection in the customer premises equipment

FR network acces node Frame Relay

Status FR network node

Maximum number of PVCs and maximum frame length

Control Field 1 byte

Sequence Numbers N203 = 11 bytes + (5 bytes * 100) = 511 bytes

PVC Status 1 Example 2:

3 Switched Virtual Circuits (SVC’s)

SVC Signalisierungsnachrichten zum DCE

SVC Signalisierung SVC Signalisierung

Physical Layer Physical Layer

The following protocols are used at the network interface:

UNI NNI NNI UNI

Originating Transit Terminating

Calling User Called User

Physical Layer Physical Layer

3.1 Frame Relay in the ISDN Network

ISDN Frame Relay

Legend: Local exchange, FR exchange

Legend: Local exchange + FR exchange

ITU-T X.36 ITU-T X.36

Legend: Frame Relay network, Zero, CALL PROCEEDING