Lucent Technologies Ds1/Cept1/Isdn Pri Reference Manual

							DEFINITY Communications System Generic 2.2 and Generic 3 V2 
DS1/CEPT1/ISDN PRI Reference  
555-025-107  Issue 1
July 1993
Layers 2 and 3 
Page 5-35 ISDN PRI Layer 3 
5
NOTE:
If the servic e type of the trunk g roup is tie or tand em, c alls with any NSF on 
the trunk g roup  will b e allowed  to c omplete, regard less of whether the 
inc oming  c all hand ling  tab le is ad ministered  or not. For examp le, if the 
servic e typ e is tandem and  the inc oming  c all hand ling  tab le is b lank, any 
SDN, Meg ac om, etc ., c alls will c omp lete. Thus, the inc oming  d ig its must be 
the expected digits for routing purposes. For these calls to receive special 
treatment still req uires ad ministering  the inc oming  c all hand ling  tab le, 
however. Also, even thoug h c alls on trunk g roup s of tie and tand em are 
tand emed , the NSFs are not tand emed  — the NSF is always d etermined  b y 
the routing  p attern ad ministration.
NOTE:
Meg ac om 800 and  International 800 servic es have d ifferent NSFs, and  thus 
c annot be p ut on the same d ed ic ated trunk g roup s. These two servic es 
must b e p ut on c all-b y-c all trunk g roup s. Other U.S./g lob al servic es 
c omb inations use the same NSFs, and  thus c an be p ut on the same trunk 
g roup s. For examp le, SDN and  g lob al SDN servic es have the same NSF, 
as d o Ac c unet Switc hed  Dig ital Servic es and Switc hed  Dig ital International 
Se r vi c e s .
For details on how to imp lement the inc oming  c all hand ling  table, see the sec tion 
‘‘Inc oming  Call Hand ling  Tab le in G3V2’’
 later in this c hap ter.
NSF Implementation in the Usage Allocation Plan in the Trunk Group 
Form. 
The system also imp lements the NSF IE in the usage alloc ation p lan in the 
trunk g roup  form. This ap p lies only to ISDN PRI trunk g roup s with a servic e type 
of c b c . The servic e/feature mnemonic  in eac h row of the p lan is c ompared  with 
the fac ility c od ing  value in the NSF IE of a c all on that trunk g roup  to d etermine 
whic h row of the p lan ap p lies to the c all. For d etails of how to imp lement the 
usag e alloc ation p lan, see the sec tion ‘‘Call b y Call Servic e Selec tion in G3V2 
Systems’’ later in this chapter.
NSF Implementation in the Network Facilities Form. 
The network facilities form 
c ontains the mnemonic s for the fac ility c od ing  values of eac h NSF IE used  b y the 
system. If an NSF is not rep resented  in this form, it will not b e rec og nized  b y the 
system. This form is also used  for ad d ing  new NSFs. This c an be d one only b y 
AT&T personnel with the c orrec t ad ministration p assword  level. If a new servic e 
is entered  in the form, all other relevant forms are automatic ally up d ated to 
inc lud e the new mnemonic s.
NSF Implementation in Countries other than the U. S.
At p resent, the U.S. is the only c ountry in whic h the NSF IE is used . The 
ad ministration forms for implementing  NSF IEs are availab le b ut have no use 
outsid e the U.S. 
						

							DEFINITY Communications System Generic 2.2 and Generic 3 V2 
DS1/CEPT1/ISDN PRI Reference  
555-025-107  Issue 1
July 1993
Layers 2 and 3 
Page 5-36 ISDN PRI Layer 3 
5
User-to-User Information Signaling
In ad d ition to provid ing  sig naling  to estab lish, maintain, and  terminate c alls, the 
layer 3 p rotoc ol also inc lud es signaling  allowing  end points to exc hang e 
information unrelated  to c all c ontrol. For examp le, while c all c ontrol sig naling  is 
taking  p lac e, information c an also be sent for d isp lay on the c alling  or c alled 
p artys station. This kind  of sig naling is c alled  user-to-user information sig naling . 
The exac t d efinition of what c onstitutes a user is often fuzzy, however. To some, a 
user means a terminal, station, or an ap p lic ations p roc essor c onnec ted  to a 
switc h. The AT&T networks ISDN PRI sp ec ific ation, however, seems to inc lud e a 
PBX as a user. Thus, information used  to route a c all throug h a p rivate network, 
suc h as the traveling class mark, is defined as user-to-user information. 
User-to-user information sig naling  c an b e d ivid ed  into two fund amental types, as 
follows:
nCall control message associated user-to-user information 
nTemp orary signaling  c onnec tions (TSC)
Call c ontrol message assoc iated  means that the user-to-user sig naling 
information is b eing  p assed  in c all c ontrol messag es. For examp le, the d isp lay 
information element is sent in the SETUP and  CONNec t messages. TSCs at 
p resent only exist in the AT&T network and  in p rivate G3 networks. They are 
sp ec ial sig naling c onnec tions that allow user-to-user information to b e p assed  in 
a non-c all c ontrol messag e, c alled  the USER INFOrmation messag e. Two typ es 
of TSCs exist, c all-assoc iated  TSCs (CA TSC) and  non-c all assoc iated  TSCs 
(NCA TSC).
As with c all c ontrol information, user-to-user information is transp orted  in 
information elements. The AT&T networks ISDN PRI sp ec ific ation lists the 
following  information elements as user-to-user IEs:
nConnec ted number
nRedirecting number
nCalling party subaddress
nCalled party subaddress
nHig h layer comp atib ility
nLow layer comp atib ility
nLoc king  shift to c od eset 6 or 7
nAny IEs inc lud ed  in c odeset 6 that d o not underg o p roc essing  or 
interp retation b y the p ublic  network switc hes. Cod esets are d isc ussed  
below.
nAny IEs inc lud ed  in c odeset 7
nUser-user 
						

							DEFINITY Communications System Generic 2.2 and Generic 3 V2 
DS1/CEPT1/ISDN PRI Reference  
555-025-107  Issue 1
July 1993
Layers 2 and 3 
Page 5-37 ISDN PRI Layer 3 
5
Some IEs are d efined  as c all c ontrol IEs b ut c an also b e used  for the p urp ose of 
user-to-user information sig naling . The c alling  p arty numb er, for examp le, whic h 
is d efined as a c all c ontrol IE, is often used  b y the end  user for ap p lic ations suc h 
as terminal displays.
In order to d isting uish b etween information need ed  or not need ed  b y the p ublic  
network, the c onc ep t of c od esets exists. Information elements c od ed  as b eing  
p art of c od eset 0 is information need ed  b y the pub lic /international network and  is 
d efined  b y the CCITT stand ard. Information elements in c od esets 1-4 are 
reserved for future stand ard s. Cod eset 5 is used  for the pub lic  network in the 
U.S. Cod eset 6 is used  b y p rivate networks. Cod eset 7 is information need ed b y 
the end  user. In p rac tic e, the d ivision b etween c od esets 6 and  7 is not always 
c lear b ec ause c odeset 6 information often looks like end  user information.
All DEFINITY systems allow some degree of codeset mapping, which is the 
c ap ab ility to sp ec ify whic h c od eset an IE will b e sent in. G3V2 systems limit this 
map p ing  to user-to-user information elements in the outg oing  d irec tion. G2.2 
systems, however, allow any IEs to b e map p ed  to any c od eset in the inc oming  
and  outg oing  d irec tions. In theory, this c ould  b e d one for b oth c all c ontrol and  
user-to-user information signaling. In practice, however, it is used to map 
user-to-user information elements.
NOTE:
Pub lic  network switc hes in many c ountries d o not p ass c od eset 6 and  
codeset 7 IEs.
Codeset Mapping in G2.2 Systems
Bec ause switc hes sometimes d iffer in the c od esets in whic h c ertain ISDN 
information elements are sent and  also in the values of the op c od es of those 
information elements, G2.2 systems have the c ap ab ility to map  the c od esets and  
the opc od es to ac c ommod ate these d ifferent imp lementations ac ross systems. 
For examp le, the System 85 R2V4 imp lements the TCM, lookahead  interflow, and  
d isp lay IEs in c od eset 7 whereas the G2.2 and  G3V2 systems imp lement them in 
c od eset 6 b y d efault. If the G2.2 must p ass these IEs to or from the R2V4, it must 
map  them from c od eset 6 to c od eset 7 in the outg oing  d irec tion and  from 
c od eset 7 to 6 in the inc oming  direc tion.
Cod eset map p ing is imp lemented  in p roc ed ure 280, word  1 as follows: 
1. An ind ex in the rang e 0 to 15 is assig ned in field  1.
2.Incoming
 is selec ted in field  2.
3. A c od eset to b e map p ed  in the inc oming  d irec tion is selec ted  in field  3.
4. An op c od e (information element) b elong ing  to the selec ted  c od eset is 
selec ted  in field  4.
5. The c od eset on the G2.2 to whic h the inc oming  c od eset from field  3 is to 
be mapped is selected in field 5. 
						

							DEFINITY Communications System Generic 2.2 and Generic 3 V2 
DS1/CEPT1/ISDN PRI Reference  
555-025-107  Issue 1
July 1993
Layers 2 and 3 
Page 5-38 ISDN PRI Layer 3 
5
6. The op c od e on the G2.2 to whic h the inc oming  op c od e from field  4 is to 
be mapped is selected in field 6.
7. Step s 2 throug h 6 c an be rep eated  up  to 256 times for the inc oming  c ase.
8.Outgoing
 is selec ted  in field  2 and  step s 3 throug h 7 are rep eated . For 
every inc oming  map p ing there should  b e an id entic al outg oing  map p ing .
9. All of the ab ove step s c an b e rep eated  up  to 16 times (the numb er of map  
numb ers availab le).
10. For eac h ANN35 or TN767 c ontaining a p rimary D-c hannel to whic h you 
want a c odeset map ping , assign the map numbers in p roc ed ure 262, 
word  3. Note that d ifferent interfac es c an use d ifferent map p ing s for the 
same c od esets and op c od es. For examp le, one interfac e c an map  the 
TCM to c odeset 7 while another interfac e c an map the TCM to c od eset 0.
Tab le 5-4
 summarizes the c urrent c od eset map p ing  req uirements for the G2.2:
Codeset Mapping in G3V2 Systems
G3V2 systems allow limited  c od eset map p ing  in the outg oing  d irec tion. 
Table 5-4. G2.2 Codeset Mapping Requirements
IE Codeset Map Opcode Map When Required
TCM Map  from c od eset 6 to 
c od eset 7 outg oing . 
Map from codeset 7 to 
codeset 6 incoming.Map from op c od e 8 to 
op c od e 8 in b oth 
d irec tions.If a System 85 R2V4 
is present in an 
end -to-end  ISDN 
network with the 
G2.2, this c od eset 
mapping is 
req uired .
Disp lay Map  from c od eset 6 to 
c od eset 7 outg oing . 
Map from codeset 7 to 
codeset 6 incoming.Map from op c od e 40 to 
op c od e 40 in b oth 
d irec tions.If a System 85 R2V4 
is present in an 
end -to-end  ISDN 
network with the 
G2.2, this c od eset 
mapping is 
req uired .
Lookahead
InterflowMap from codeset 6 to 
c od eset 7 outg oing . 
Map from codeset 7 to 
codeset 6 incoming.Map from op c od e 123 
to op c od e 123 in b oth 
d irec tions.If a System 85 R2V4 
is present in an 
end -to-end  ISDN 
network with the 
G2.2, this c od eset 
mapping is 
req uired . 
						

							DEFINITY Communications System Generic 2.2 and Generic 3 V2 
DS1/CEPT1/ISDN PRI Reference  
555-025-107  Issue 1
July 1993
Layers 2 and 3 
Page 5-39 ISDN PRI Layer 3 
5
G3V2 systems allow the TCM and  lookahead  interflow IEs to b e sent in either 
c od eset 6 or 7. In the inc oming  d irec tion, these systems ac c ep t these IEs in 
either c od eset 6 or 7. You administer this in the trunk g roup  form in the field  
Codeset to Send TCM/Lookahead
. G3V2 systems also allow the d isp lay IE 
to b e sent in c od eset 0, 6, or 7. This is b ec ause many c ountries p ub lic  network 
switc hes do not p ass c od eset 6 or 7 information. In the inc oming  d irec tion, G3V2 
ac c epts the d isp lay IE in either c od eset 0, 6, or 7. You ad minister this in the trunk 
g roup  form in the Send Display in Codeset 0/6/7
 field .
Call Control Message Associated 
User-to-User Information Signaling
User-to-user information c an b e p assed  in information elements in layer 3 c all 
c ontrol messag es. In CCITT terminolog y, this is simp ly c alled  user to user 
information sig naling . The AT&T sp ec ific ation, however, c alls this typ e of 
sig naling  messag e assoc iated  user to user information (MA UUI). This d istinc tion 
is nec essary bec ause the AT&T spec ific ation also d efines ways to exc hang e 
user to user information in messag es other than c all c ontrol messag es. The 
following  sec tions d esc rib e the information elements used  in user to user 
information sig naling  assoc iated  with c all c ontrol messag es in DEFINITY 
systems.
Connected Number IE
The DEFINITY systems send  the c onnec ted  number in c od eset 0 in the CONNec t 
messag e. Its p rimary use is to ind ic ate the c onnec ted  p artys numb er on the 
c alling  p artys station d isp lay. For the c onnec ted  numb er to b e sup p lied  ac ross a 
p ublic  network, the DEFINITY system and  the far end  end p oint must b e on ISDN 
ac c ess to the LEC or toll offic e switc h. For examp le, if you rec eive a c all from a 
far-end  switc h that is c onnec ted  to a p ub lic  network switc h with b it-oriented  
sig naling  ac c ess, you c annot rec eive the c onnec ted  number. 
Numbering Plan and Type of Number. 
When sending  a c onnec ted  numb er IE, 
G2.2 systems p op ulate the Numbering Plan ID
 and  Type of Number
 field s 
in the following  way:
G3V2 systems p opulate these two field s as follows:Type of Number
National Numb er
Numbering Plan Identification
Telephony Numb ering  Plan
Type of Number
National Numb er
Numbering Plan Identification
ISDN/telep hony numb ering plan 
rec ommend ation E.164/E.163 
						

							DEFINITY Communications System Generic 2.2 and Generic 3 V2 
DS1/CEPT1/ISDN PRI Reference  
555-025-107  Issue 1
July 1993
Layers 2 and 3 
Page 5-40 ISDN PRI Layer 3 
5
Requirements for Sending Connected Number IE. 
In G2.2 systems, to send  the 
c onnec ted  numb er, the NPA-NXX d esig nator field  in p roc ed ure 354, word  3 must 
b e ad ministered . This d esig nator must also b e entered  in p roc ed ure 000 for the 
c onnec ted  p artys extension. The numb er sent is then always of the form 
NPA-NXX-extension, a 10-d ig it d irec t d istanc e d ial (DDD) numb er. Also, 
p roc ed ure 100, word  3, field  8 must be set to 0
 or 2
 to send  the op tional 
information elements. When set to 2
, the op tional IEs are sent, b ut if the trunk 
g roup  is a DCS trunk group  on an ISDN fac ility and  an ISDN c all from another 
trunk g roup  is routed  to it, the DCS name messag e is sup p ressed .
In G3V2 systems, to send  the c onnec ted  numb er information element to the 
c alling  p arty on the far end , the CPN p refix table form must be ad ministered  and  
the Send CPN
 field  in the trunk g roup  form must be ad ministered  as yes
. This 
tab le allows you to sp ec ify the numb er to b e p ut in the c onnec ted number IE for 
any g iven extension. The Send CPN
 field  in the trunk g roup sc reen must also be 
ad ministered  as y
. In G3V2, this numb er c an b e any leng th from 0 to 15 d ig its. 
For g uid elines on how to ad minister the CPN prefix table, see the sec tion ‘‘Calling  
Party Number IE’’ earlier in this c hapter.
Display Requirements for Connected Number IE. 
On G2.2 systems, no 
ad ministration is nec essary to d isp lay the c onnec ted  p arty numb er. As they are 
being dialed, the dialed digits are displayed until the last digit is dialed. As the 
c all is p rog ressing , OUTSIDE CALL
 is displayed if the names database and the 
outg oing  d isp lay are ad ministered  in p roc ed ure 012. If either of these is not 
ad ministered , the d ialed dig its c ontinue to be d isp layed. When c onnec ted , the 
far end  may send  b ac k the c onnec ted  numb er and  the d isp lay IE in the 
CONNec t messag e. If b oth are present, b oth are disp layed . If only one IE is 
present, it is displayed. 
On G3V2 systems, to d isp lay the c onnec ted  numb er if sent from the far end , no 
ad ministration is nec essary. To overwrite the dialed  d igits d isp lay with the trunk 
g roup  name after the c all is d ialed  b ut b efore c onnec ted , the Outgoing 
Display
 field  in the trunk g roup  form must b e set to yes
 and  the trunk g roup  
name must b e ad ministered .
As they are d ialed , the d ialed  d ig its are d isp layed . Before c onnec ted , this 
d isp lay may b e overwritten b y the outgoing trunk g roup  name, d epend ing  on 
ad ministration. When c onnec ted , the far end  send s b ac k the c onnec ted  numb er 
IE and  the d isp lay IE in the CONNec t messag e and  the d isp lay c hang es. If both 
are p resent, they are b oth d isp layed . If only one IE is p resent, it is d isp layed . If 
only the connec ted number is present, the display shows Answered By
 and the 
number.
Display IE
All DEFINITY systems send  the disp lay IE in either c od eset 0, 6, or 7, d ep end ing  
the system and  on ad ministration. G2.2 systems and  G3V2 systems allow the 
d isp lay IE to b e map p ed  to c od eset 0, althoug h for ap p lic ations in the U.S. it 
should  b e sent in either codeset 6 or 7. The d isplay IE is sent in either the SETUP 
messag e or the CONNec t message. When sent in the SETUP messag e, its  
						

							DEFINITY Communications System Generic 2.2 and Generic 3 V2 
DS1/CEPT1/ISDN PRI Reference  
555-025-107  Issue 1
July 1993
Layers 2 and 3 
Page 5-41 ISDN PRI Layer 3 
5
p urp ose is to d isp lay the c alling p arty name for d isp lay on the c onnec ted  p artys 
terminal, thoug h anything  in the IE will b e displayed . When sent in the CONNec t 
messag e, its purpose is to d isp lay the c onnec ted partys name on the c alling  
p artys terminal, thoug h anything  in the IE will b e d isp layed . The ap p rop riate 
c od eset in whic h to send  the d isp lay IE d ep end s on the p ub lic  network 
req uirements of the c ountry or on the p rivate switc h to whic h the DEFINITY 
system is c onnec ted . In g eneral, in the U.S. the d isp lay IEs should  b e sent and  
rec eived  in c odeset 6 on the DEFINITY systems unless a System 85 R2V4 is 
p resent somewhere in the network (an SDN-with-ISDN network or an ETN for 
examp le). In this case, it should  b e sent in c od eset 7. This is because the System 
85 send s and  rec eives the d isp lay IE (as well as the TCM) in c odeset 7.
Requirements for Sending the Display IE in the SETUP Message. 
G2.2 
systems will send  the d isp lay IE if p roc edure 100, word  3, field  8 is set to 0
 to 
send  the op tional information elements. Also, the name must b e ad ministered  in 
the names d atab ase in p roc ed ure 012. The c ontents of the names d atabase 
p opulates the d isp lay IE that is sent in the b oth the SETUP and  CONNec t 
messag es. Thus, more information than the name c an b e d isp layed if the d isp lay 
IE c ontains more than the name-only. You must also map  the c od eset you want 
the d isp lay IE to b e sent in by administering  p roc ed ure 280, word  1.
In G3V2 systems, to send  the d isp lay IE, the Send Name
 field  in the trunk g roup  
form must b e set to y
. The name assoc iated  with the extension is ad ministered  in 
voice terminal forms. On G3V2 systems in the U.S., the d isp lay IE should b e sent 
in c od eset 6 unless a system that d oes not sup p ort these IEs in c od eset 6, suc h 
as a System 85 R2V4, is p resent in the network, in whic h c ase it should  b e set to 
7
. In other c ountries, the d isp lay IE c an b e sent in c od eset 0 if nec essary.
Requirements for Displaying the Display IE. 
All DEFINITY systems always 
d isp lay the c ontents of the d isp lay IE if sent from the far end . If b oth the d isp lay 
IE and  c alling  p arty numb er are sent from the far end , b oth will b e d isp layed . 
Display IE Interactions with DCS Messages. 
When b oth the ISDN PRI messag e 
and  the DCS message are availab le on a c all (when DCS messag es are 
transported  over PRI trunks, for examp le) the c ontents of the DCS messag e are 
displayed except in the following cases:
nIn G3V2 systems, when an inc oming  c all on a DCS trunk is routed  to an 
outg oing  ISDN PRI-only trunk, the c ontents of the display information 
element in the ISDN PRI SETUP messag e, whic h c ontains the c alling  p arty 
name, are taken from the c ontents of the DCS name messag e.
nWhen an inc oming  c all on an ISDN PRI trunk is routed  to an outg oing  DCS 
trunk over an ISDN PRI trunk, the DCS name messag e is sup p ressed  in 
G3V2 systems. G2.2 systems also sup p ress the DCS name message in 
this situation b ut only if p roc ed ure 100, word 3, field  8 is ad ministered  as 
2
. The reason for this is that the DCS name messag e in this c ase only 
c ontains the trunk group  name, if ad ministered , of the inc oming  ISDN PRI 
trunk. Sinc e DCS messag es normally take p rec ed enc e, the more 
informative ISDN PRI display IE would not b e used . Thus, the DCS name 
messag e is turned  off, allowing  the ISDN PRI d isp lay IE to b e used . 
						

							DEFINITY Communications System Generic 2.2 and Generic 3 V2 
DS1/CEPT1/ISDN PRI Reference  
555-025-107  Issue 1
July 1993
Layers 2 and 3 
Page 5-42 ISDN PRI Layer 3 
5
Lookahead Interflow IE
All DEFINITY systems p op ulate the lookahead  interflow IE with the c ontents of the 
names d atab ase for the listed  VDN of the orig inating  system.
Low Layer Compatibility IE
The low layer c omp atib ility IE is used  to tell an end p oint, trunk g roup , or routing  
p referenc e, the c harac teristic s of the assoc iated  c all on the B c hannel. These 
c harac teristic s inc lud e suc h thing s as whether the c all is voic e, restric ted  d ig ital 
d ata, the user d ata rate, and  whether it is sync hronous or async hronous. This 
information is used  b y the rec eiver to d etermine whether it is c omp atib le with the 
c all and  to take the ap p ropriate ac tions.
In DEFINITY systems, information from the b earer c ap ab ility IE and the low layer 
c omp atib ility IE is c omp ared  with the information from the ad ministered  b earer 
c ap ab ility c lass and  information transfer c ap ab ility of an end p oint, trunk g roup , 
or routing  p referenc e to do the following:
nRou te c a ll s 
nInsert modem pools
nAc c ep t or b loc k c alls at the end point b ased  on c omp atib ility 
Bearer c apab ility c lass (BCC) and  information transfer c apab ility (ITC) are 
ad ministrab le attrib utes d esc rib ing  the typ es of c alls sup p orted  b y a terminal, 
trunk g roup , or routing  p referenc e. Tog ether the BCC and  ITC p op ulate the 
b earer c ap ab ility IE and  the low layer c omp atib ility IE on outg oing  c alls. For 
examp le, mod e 2 data is a b earer c ap ab ility c lass and  restric ted  d ata is an 
information transfer c ap ab ility (these are DEFINITY terms, not ISDN PRI terms). If 
a c all to an ISDN PRI trunk group  is mad e from a mod e 2 d ata mod ule 
ad ministered  as restric ted  d ata on the d ata mod ule form in a G3V2 at a user d ata 
rate of 9.6 kb p s, for examp le, the ISDN PRI messag e formed  for this c all will 
c ontain a b earer c ap ab ility IE and  a low layer c omp atib ility IE. The b earer 
c ap ab ility IE for this c all is p op ulated with information suc h as the fac t that it is 
restricted digital information at a 64 kbps information transfer rate (mode 2 uses 
64 kbps even though the user data rate is only 9.6 kbps). The low layer 
c omp atib ility IE for this c all is also p op ulated  with restric ted  d ig ital information at 
a 64 kb p s transfer rate. It is also p op ulated  with other information suc h as the 
user data rate of 9.6 kb p s.
The BCC and  ITC also ap p ly to non-ISDN c alls. With inc oming  non-ISDN c alls, 
however, it is hard er to d etermine the c harac teristic s of the c all b ec ause there is 
no BC IE or LLC IE to c onvey that information.
BCC and ITC Implementation in G3V2 Systems. 
The p rimary use of the BCC 
and  ITC in G3V2 systems is to p op ulate the BC IE and  LLC IE on c alls to ISDN 
PRI trunk g roup s and  to imp lement b earer c apab ility routing  (c alled g eneralized  
route selec tion, or GRS, in G3V2 systems). 
G3V2 systems p opulate the BC IE and  LLC IE in the following way: 
						

							DEFINITY Communications System Generic 2.2 and Generic 3 V2 
DS1/CEPT1/ISDN PRI Reference  
555-025-107  Issue 1
July 1993
Layers 2 and 3 
Page 5-43 ISDN PRI Layer 3 
5
nFor c alls from non-ISDN end p oints to ISDN PRI trunks, the BC IE and LLC 
IE, except for the information type codepoint, is populated automatically 
b ased on the typ e of end point. For examp le, if the endp oint is an MPDM 
set for mod e 1 op eration, the BC IE and  LLC IE are p op ulated  with mod e 1 
c harac teristic s. Two exc ep tions to this rule exist as follows:
— A c all from a mod e 2 end point is routed  to a p attern c ontaining  
voic e preferenc es b ut no mod e 2 preferenc es. In this c ase a 
mod em p ool is inserted  and  the outg oing  BC IE and  LLC IE in the 
ISDN PRI messag e is p op ulated  b y the BCC and  ITC ad ministration 
of the p referenc e, not the orig inating  end point.
— A c all from a voic e end p oint is routed  to a p attern c ontaining  
p referenc es ad ministered  only for d ata (BCCs 1, 2, 3, or 4). In this 
c ase, the outg oing  ISDN PRI message is p op ulated  b y the BCC 
and  ITC ad ministration of the p referenc e, not of the orig inating  
endpoint.
nIn G3V2, the information typ e c od ep oint in the BC IE and  LLC IE is c od ed  
from the ad ministered  ITC field  on the d ata module form.
nAs with G2.2, for c alls from ISDN end p oints to ISDN PRI trunks, the BC IE 
and  LLC IE are p op ulated  b y the end p oint at the time the c all originates. 
Op tion settings on the ISDN set d etermine the various BC IE and  LLC IE 
c od ep oints, suc h as transfer rate and  information typ e.
NOTE:
International d ata c alls req uire the information typ e in the BC IE to b e 
c od ed as unrestric ted . In G2.2 and  G3V2 you c an c ontrol this in 
ad ministration.
The following  list exp lains some of the imp lementation d etails of b earer c ap ab ility 
routing :
nGRS works only if ISDN-PRI
 is assig ned  in the system parameters - 
c ustomer op tions ad ministration form.
nGRS is used  to make outgoing c all routing  d ec isions and  mod em p ool 
d ec isions for ISDN c alls b ut only routing  d ec isions for non-ISDN c alls.
nFor non-ISDN c alls, mod em p ool d ec isions are b ased  on the trunk typ e 
(AVD or non-AVD).
nThe BCC field s in the routing  p attern form must b e ad ministered  for every 
routing  p referenc e (ISDN and  non-ISDN) if ISDN-PRI is ad ministered  in the 
system p arameters-c ustomer op tions sc reen.
nFor outg oing  ISDN c alls, the first p referenc e c ontaining  at least one matc h 
for the b earer c ap ab ility of the orig inating  end p oint will b e c hosen. If a 
matc h is not found , the following  sc heme is used :
— A c all of BCC 0 is never b loc ked . 
						

							DEFINITY Communications System Generic 2.2 and Generic 3 V2 
DS1/CEPT1/ISDN PRI Reference  
555-025-107  Issue 1
July 1993
Layers 2 and 3 
Page 5-44 ISDN PRI Layer 3 
5
— A c all of BCC 2 will use a preferenc e with BCC 2 set to yes
. If no 
suc h p referenc e exists, it will searc h for a p referenc e with BCC 0
 
set to yes
. Failing  this matc h, the c all is b loc ked  with interc ep t.
— A c all of BCC 1, 3, or 4 will b e b loc ked  with interc ep t.
— Calls from mode 2 end p oints must b e routed  to p referenc es with 
BCC 0 set to yes and  BCC 2 set to no to rec eive a mod em pool.
In G3V2 systems the administered ITC is also used to make routing decisions for 
outg oing  c alls. Sinc e the ITC d esig nates whether the d ata is restric ted  or 
unrestric ted , this administration p rob ab ly only ap p lies to U.S. systems b ec ause 
other c ountries d o not have restric ted  fac ilities.
NOTE:
Ac c unet Switc hed  Dig ital International 64 kb p s c alls must b e administered  
as unrestric ted , for all b ut mod e 1 c alls.
The fund amental rule for the ITC is that the ad ministered  ITC of the routing 
p referenc e, whic h indic ates whether restric ted d ata or unrestric ted  d ata is 
sup p orted  on that p referenc e, must not c onflic t with the ITC of the c all, whic h 
ind ic ates whether the d ata is restric ted  or unrestric ted . If these two c onflic t, the 
c all is b loc ked . The following  list d esc rib es the c omp atib ility of the ITC of a c all 
and  the ad ministered  ITC of a routing  p referenc e:
nMod e 0 d ata is restric ted  or unrestric ted dep end ing  on whether the 
orig inating  terminal p ac kag es it in a p rotoc ol g uaranteeing  1s d ensity. For 
examp le, mod e 0 from an MPDM is always unrestric ted  unless the 
orig inating  terminal on the MPDM p erforms some kind  of 1s d ensity 
p rotoc ol pac kag ing , suc h as inverted  HDLC.
nMod e 1 d ata is restric ted .
nMod e 2 d ata is restric ted .
nMod e 3 d ata is restric ted  or unrestric ted, d ep end ing  on whether the 
terminal or d ata mod ule inverts the b its.
nReg ard less of the nature of the data b eing  transp orted , the ITC c an b e set 
to restric ted  or unrestric ted either throug h ad ministration or b y op tion 
setting s on the terminals. For examp le, mod e 2 d ata is, b y d efinition, 
restric ted  d ata, b ut you c an ad minister a mod e 2 MPDM as unrestric ted , if 
the app lic ation req uires it. This is req uired  when making  international 
ISDN PRI data c alls, for examp le.
nRestric ted  d ata c an b e transp orted  over restric ted  or unrestric ted  
facilities.
nUnrestric ted  d ata c an b e transp orted over unrestric ted  fac ilities only.
nIf a routing  p referenc e is a trunk g roup  c onnec ted  to a DS1 interfac e 
ad ministered  as ZCS line c od ing , it must b e administered  to sup p ort 
restric ted  d ata.