UDI vs RDI in ISDN
Al Varney
<psy...@metronet.com> wrote:
> In the world of ISDN, what exactly does UDI and RDI mean? And when
> would a person know which one to use? (e.g. you try making a UDI call
> and then realize that it doesn't work, so then you try RDI? What kind
> of indications does the network use to determine what to do?)
UDI = unrestricted digital information -- also called 64U or "64 clear"
or 64C
RDI = restricted digital information -- also called "64 restricted"
or 64R or sometimes 64I
An ISDN user does not make a UDI or RDI call. UDI/RDI is one part
of the Bearer Capability information passed to/from the network.
Specifically, the "information transfer capability" can be set to
either UDI or RDI. The "information transfer rate" for a data call
would then be set to "64 kbps". Together, the two parts are used to
request 64K IDSN data calls, commonly abbreviated as 64U or 64R calls.
Sometimes the 64U calls are calls "64 clear" or 64C; the "clear"
signifies that the channel is "clearly" or transparently carrying all
data values. The 64R calls can be used to allow calls over facilities
(or trunks or circuits) that are not capable of transporting all data
values -- specifically the 8-bit value "0" (or "11111111" if you are
inverting data before transmission) cannot be carried. The requester
of an RDI call is responsible for ensuring no "0" values are
transmitted -- if they occur, the network will alter at least one bit
to enforce the restriction.
The "network" attempts to complete calls using the information in
the Bearer Capability you provide and information provided by the
operator of the network. If you request UDI, the call will route (or
attempt to route) over facilities that have been designated by the
operator as supporting UDI. If the facilities don't, in fact, support
UDI -- you get some of your bits mangled. But this is no different TO
THE NETWORK than routing you over a bad facility -- the facility is
not working as the switches have been told it does.
> I think that UDI is supposed to be a 64kbps clear channel xmission
> (and I think you can have an RDI call over a trunk conditioned for UDI).
If you request RDI, then the network (switches) will route over
facilities designated to support RDI, and will use UDI routes if no
RDI facilities are available. Regardless of what that switch selects,
the switch at the other end of the selected facility will receive the
same Bearer Capability you originally requested, so that it can
attempt to select a trunk from all the original possibilities.
The above "rules" apply to SS7-connected switches which are
carrying the selected UDI/RDI request via SS7 signaling. I understand
RDI can be a problem when calling out of or into the USA, since many
countries use E1 (vs. T1) facilities that do not have a data value
restriction.
> And I think that RDI means that the data is restricted in the
> sense that you can't have some number of contiguous 0's, which
> effectively reduces the maximum bit rate to 56kbps, right? But then,
^^^^^
NO!
> could you try sending data at 64kbps for an RDI call or is one of the
> bits for each channel used to keep sync (I'm assuming this is over T1
> type trunks for RDI; I guess E1 type trunks don't have this problem
> and are 64kbps clear channel trunks by nature?).
The 56 kbps bit rate vs. RDI is confusing. I can't assure you that
I can un-confuse the issues. RDI is a restriction on 8-bit data
values; the value "00000000" is prohibited. But there is no rate
adaption or change to the data rate implied by RDI. You send at 64
kbps, period. The reason for RDI is due to T1 facilities that don't
use B8ZS or other schemes to remove the original T1 restriction that
no more than 15 "0"s could be sent over the facility -- more "0"s
meant loss of sync. (Some pre-B8ZS schemes used non-adjacent channels
for data or borrowed bits from a control channel to remove the RDI
restriction.)
The use of 56 kbps in the USA/Canada and a few other T1 countries
came about because one bit of the channel was sometimes used as a
signaling bit (on-hook,off-hook indicator). In standard T1, this
happens in every sixth frame. Because the sixth frame on one circuit
isn't the sixth frame on another, the 1-out-of-6 position cannot be
predicted end-to-end. This effectively removes the ability to use 8
bits -- 7 bits at the 8000 frames/second T1 rate yields 56 kbps.
When SS7 signaling is used, switches don't need the signaling bit
in the T1 channel. For some switches, this permits 64 kbps over RDI
as soon as SS7 is implemented between 2 switches. Others require
hardware upgrades to remove the "hard-coded" signaling bit. But even
when the signaling bit is removed, the T1 transport facility still
can't handle unrestricted data -- that requires a change to the
facility (sometimes a hardware upgrade, sometimes just changing data
in the facility).
From an ISDN end-point, 56 kbps is a V.120 rate adaption scheme.
The network knows which bit to ignore (and force to a "1"). The far
end end-point will get 64 kbps data, and will ignore the eighth bit.
> But, 64kbps or 56kbps doesn't necessarily mean UDI and RDI, respectively,
> does it?
Correct. You can, in theory, use UDI or RDI with 64 kbps calls.
Or you can use UDI or RDI with 64 kbps calls rate adapted to 56 kbps.
To confuse the issue, Bellcore requirements for ISDN don't recognize
RDI, so they only talk about 64 kbps via UDI and 56 kbps rate adaption
over 64 kbps via UDI. Unfortunately, there are some vendors who
adopted the rule that 56 kbps calls would use an "information transfer
capability" of RDI. When connecting to networks/equipment that only
recognizes an "information transfer capability" of UDI, the call will
be refused.
Also, some carriers (LEC and IXC) may still have some 56Kbps
facilities (trunks and "switched 56" customers). If such trunks are
in the path of the call (which could start out 56 kbps with UDI or
with RDI, the switches/customer beyond the 56Kbps facility receive
only the called number -- and must assume a value of UDI or RDI for
your 56Kbps call. The value assumed depends on the network, the
switch and lots of other semi-random information.
> And how does rate adaption come into the picture? Is it possible to
> have 9600bps data stream rate adapted up to 56kbps for RDI? or up to
> 64kbps for UDI? Is V.120 or V.110 common in the U.S.? What is
> commonly used overseas? What are the advantages of V.120 over V.110
> or are there not any?
V.120 common in USA. V.110 common in Europe. V.120 is more
flexible, but has some added overhead. V.110 has less overhead if you
can keep its fixed sub-channels full of data. 9600 bps is supported
by both. Since 56 kbps is itself a rate adaption, it's hard to say
9600 bps is supported by 56 kbps -- I believe you could indicate 56K
in the Bearer Capability rate adaption and would use LLC to indicate
the actual partitioning of one or more 9600 bps over the 64 kbps
B-channel. (Keep in mind that the ISDN end-points never actually
transmit at anything other than 64 kbps.) If I remember correctly,
V.120 rate adaption for 9600 bps forces 1 out of the 8 bits to a "1",
so the same bit pattern would work over both 56 kbps or 64 kbps calls,
whether UDI or RDI.
Asking a more specific question on comp.dcom.isdn might get you a
more correct (and shorter) answer ...
Al Varney - just my opinion
Kevin Paul Herbert
particular ones density. This can be used to transmit HDLC data if you
invert the bits; HDLC has a different reason for avoiding 6 one bits
in a row; by inverting this, you can assure that there are never 6
zero bits in a row.
I'm not sure if RDI is actually supported anywhere.
Kevin