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-45 ISDN PRI Layer 3 
5
nIf a routing  p referenc e is a trunk g roup  c onnec ted  to a DS1 interfac e 
ad ministered  as B8ZS or HDB3 line c od ing , it c an b e ad ministered  to 
sup p ort unrestric ted  d ata, restric ted  d ata, or both.
Given the ab ove rules, the rules for ITC are as follows:
nIf the ITC of the originating end p oints data is restric ted , and  the 
ad ministered  ITC of the p referenc e is restric ted , the c all is allowed .
nIf the ITC of the originating end p oints data is restric ted  and  the 
ad ministered  ITC of the p referenc e is unrestric ted , the c all is b loc ked  with 
intercept.
nIf the ITC of the originating end p oints data is unrestric ted  and  the 
ad ministered  ITC of the p referenc e is restric ted , the c all is bloc ked with 
intercept.
nIf the ITC of the originating end p oints data is unrestric ted  and  the 
ad ministered  ITC of the p referenc e is unrestric ted , the c all is allowed .
nIf the ad ministered  ITC of the p referenc e is both
, then the c all is allowed  
reg ard less of ITC of the end p oints d ata. In this c ase, a d ec ision must b e 
mad e as to how the ITC in the BC IE and the LLC IE is c od ed . This is d one 
b y using  the value in the BCIE
 field . If this field  is set to ept
, the ITC from 
the end p oint is used . If set to unr
, the ITC sent will b e unrestric ted .
nThe ITC of the endp oint is ad ministered  in the d ata mod ules ad ministration 
form for non-ISDN end points. For ISDN d ata mod ules the ISDN messag e 
g enerated  b y the terminal p op ulates the ITC and  the switc h ad ministration 
for that extension is ig nored . This messag e is p opulated  either 
automatic ally b y the terminal or b y an op tion setting  on the terminal, 
d epend ing  on the partic ular terminal. The only c ase where switc h 
ad ministration p op ulates the ITC for c alls from ISDN terminals is when the 
terminal is administered as an acc ess endpoint. Modes 0, 1, and 3 c an be 
set to restric ted or unrestric ted  with an op tion setting on the d ata mod ule.
All incoming  calls to an end p oint are allowed  to comp lete, leaving  it to the 
endpoints to decide on c ompatibility. Incoming voic e or voice-grade data calls to 
any digital endpoint will automatically receive a modem pool.
NOTE:
The U.S. is the only c ountry using restric ted  fac ilities. If you make a d ig ital 
d ata c all to Europ e over Ac c unet Switc hed  Dig ital International servic e, for 
examp le, the ITC in the BC and  LLC IEs must b e c od ed  as unrestric ted  
exc ep t in the c ase of mod e 1 c alls.
BCC and ITC Implementation in G2.2 Systems. 
G2.2 systems p op ulate the BC 
IE and  LLC IE in the following  way:
nFor c alls from non-ISDN end p oints to ISDN PRI trunks, the BC IE and LLC 
IE are pop ulated  from the b earer c ap ab ility c lass of servic e ind ic ated in 
field s 15 and  16 of p roc ed ure 014, word  1 and  assig ned  to the end p oint in 
p roc ed ure 000, word  3, 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-46 ISDN PRI Layer 3 
5
nFor c alls from ISDN endp oints to ISDN PRI trunks, the BC IE and  LLC IE 
are p opulated  b y the end p oint at the time the c all orig inates. Op tion 
setting s on the ISDN set determine the various BC IE and  LLC IE 
c od ep oints, suc h as transfer rate and  information typ e.
G2.2 systems implement the G3V2 eq uivalent of GRS in a feature c alled Bearer 
Cap ab ility Class of Servic e (BCCOS). A BC COS is a user-d efinab le set of 
attrib utes assig ned  throug h ad ministration to the following  ob jec ts:
nExtensions
nAAR/ARS routing  p attern p referenc es
nTrunk groups
You c an d efine up  to 256 BC COSs (0 - 255), b ut BC COSs 0 throug h 8 are 
p re-defined . These p re-d efined  BC COSs should  not b e red efined . Rather, a new 
BC COS should be defined whenever you want to redefine a pre-defined BC 
COS.
To imp lement BC COS prop erly, you must have the following  d oc ument:
DEFINITY® Communic ations System Generic  2 Ad ministration Proc ed ures. The 
tab le of p re-d efined  BC COSs in p roc ed ure 014 is c ruc ial.
BC COS is imp lemented by d efining  BC COSs in p roc ed ure 014, word 1, and  
assig ning  them to extensions in p roc ed ure 000, word 3, routing  p referenc es in 
p roc ed ure 318, word  2, and trunk g roup s in p roc ed ure 100, word  2. The 
attrib utes c omp osing  a BC COS are d esc rib ed  b y the setting s of field s 2 - 16 in 
procedure 014. The settings of these fields for a given BC COS define how the 
extension, p referenc e, or trunk g roup  assig ned  that BC COS will treat c alls mad e 
to that extension, p referenc e, or trunk g roup  b ased  on the b earer c ap ability and  
information typ e fields of the BC COS of the c alling extension or trunk.
The remaind er of the topic s in this sec tion exp lain the d etails of imp lementing BC 
COS.
At p resent, the following  b earer c ap ab ility c lasses are d efined  in the G2.2:
nVo i c e
nVoic e Grad e Data
nMode 0
nMode 1
nMode 2
nMode 3
nUnknown Digital
nUnknown Analog 
						

							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-47 ISDN PRI Layer 3 
5
nMod e 3/2 Ad ap tive
nX. 2 5
In ad d ition to the ab ove b earer c ap ab ility terms, the following  terms are used  as 
c onventions in this d isc ussion of BC COS:
nObject
 is used  as an abb reviation for any one of the following :
— extension
— trunk/trunk g roup
— AAR/ARS preference
nISDN extension
 is an ISDN BRI terminal.
nISDN trunk/trunk group
 is an outg oing  or inc oming  trunk or trunk g roup  
carrying ISDN calls.
nISDN preference
 is an AAR or ARS preference used to route ISDN calls.
nNon-ISDN extension
 is a DCP or analog  extension.
nNon-ISDN trunk/trunk group
 is a DS-1 or analog  trunk/trunk g roup .
nNon ISDN preference
 is a p referenc e used  to route c alls to non-ISDN 
trunk g roup s.
The following  three sec tions d esc rib e how BC COS op erates d ep end ing  on 
whether an extension or trunk in the G2.2 is c alling  another extension, trunk 
g roup , or preferenc e in the system.
NOTE:
Field s 2 and  14 of proc edure 014, word  1, are not used  at this time.
1. Extension or Trunk Calling  Extension
The following  list d esc ribes the BC COS operation when a trunk or 
extension c alls an extension in the system:
nThe b earer c ap ab ility of the c alling  extension or trunk is p resented  
to the c alled  extension. This b earer c ap ab ility is d erived  in d ifferent 
ways d ep end ing  on the typ e of c all as follows:
— For a c all from a non-ISDN extension or trunk to an 
extension, the b earer c ap ab ility, taken from BC COS field  16 
of the c alling  extension or trunk, is p resented  to the c alled  
extension.
— For a c all from an ISDN extension or trunk to an extension, 
the bearer capability, derived from the bearer capability 
information element and low-layer c ompatibility information 
element (if p resent) of the ISDN messag e, is p resented  to 
the c alled  extension. 
						

							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-48 ISDN PRI Layer 3 
5
— For a d ig ital d ata c all, lac king the low-layer c omp atib ility 
information element, from an ISDN extension or trunk to an 
extension, the b earer c ap ab ility p resented  to the c alled  
extension is mod e 2.
— For a c all from a non-ISDN extension or trunk, having b earer 
capability of unknown digital
, to an extension, the bearer 
c ap ab ility presented  to the c alled  extension is the c alled  
extensions b earer c ap ab ility taken from its BC COS field  16.
nThe value in the BC COS field  of the c alled  extension (one of the 
field s 4 - 13) matc hing  the p resented  b earer c ap ability of the 
c alling  extension or trunk d etermines how the c all is treated, as 
follows:
— If the field  is 0
 the c all is switc hed  to the c alled  extension. 
— If the field  is 1
 a mod em p ool memb er is inserted  and  the c all 
is switc hed  to the c alled extension.
NOTE:
Modem pool decisions are ignored for 
extension-to-extension, trunk-to-trunk, and  
trunk-to-p referenc e c alls.
— If the field  is 2
 the c all is b loc ked  with interc ep t treatment.
nThe information typ e (restric ted  or unrestric ted) of the c alling  
extension or trunk is p resented  to the c alled  extension. This 
information typ e is d erived  in d ifferent ways d epend ing  on the c all 
type as follows:
— For a c all from a non-ISDN extension or trunk to an 
extension, the information type of the c alling  extension or 
trunk, taken from BC COS field  15 of the c alling  extension or 
trunk, is p resented  to the c alled  extension.
— For a c all from an ISDN extension or trunk to an extension, 
the information typ e, d erived  from the b earer c ap ability 
information element of the ISDN messag e, is presented  to 
the c alled  extension.
nThe c alled  extensions information type, taken from field  3 of the 
c alled  extensions BC COS, is c omp ared  with the information typ e 
of the c alling  extension or trunk. Dep end ing  on these values, the 
following  ac tions are taken:
— If the information typ e of the c alling  extension or trunk is 
restricted and field 3 of the called extension is 1
 (restric ted ), 
the c all is allowed.
— If the information typ e of the c alling  extension or trunk is 
unrestric ted  and  field 3 of the c alled  extension is 0
 
(restric ted ), the c all is b loc ked  with interc ep t. 
						

							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-49 ISDN PRI Layer 3 
5
— If the two information typ es matc h, the c all is allowed . Note 
that even if the c all is allowed , you must still make sure the 
transmission fac ilities the call will use are indeed what is 
ad ministered . For examp le, if you have unrestricted
 
ad ministered  b ut the d ig ital d ata c all is mad e over restric ted  
transmission fac ilities in the network, the d ata will b e 
corrupted.
2. Extension or Trunk Calling  Trunk Group
The following  list d esc ribes the BC COS operation when a trunk or 
extension c alls a trunk g roup  in the system: 
nThe b earer c ap ab ility of the c alling  extension or trunk is p resented  
to the c alled  trunk g roup . This b earer c ap ab ility is d erived  in 
d ifferent ways d ep end ing  on the typ e of c all as follows:
— For a c all from a non-ISDN extension or trunk to a trunk 
g roup , the b earer c ap ab ility, taken from BC COS field  16 of 
the c alling  extension or trunk, is presented  to the c alled  trunk 
g roup .
— For a d ig ital c all from an ISDN extension or trunk to a trunk 
g roup , the b earer c ap ab ility, d erived  from the b earer 
c ap ab ility information element and  low-layer c ompatib ility 
information element (if p resent) of the ISDN messag e, is 
p resented to the c alled  trunk g roup .
— For a d ig ital d ata c all, lac king the low-layer c omp atib ility 
information element, from an ISDN extension or trunk to a 
trunk g roup , the bearer c ap ab ility p resented  to the c alled  
trunk g roup  is mod e 2.
— For a c all from a non-ISDN extension or trunk, having b earer 
capability of unknown digital
, to a trunk g roup, the b earer 
c ap ab ility presented  to the c alled  trunk group  is the c alled  
trunk g roup s b earer c ap ab ility taken from its BC COS field 
16.
nThe value in the BC COS field  of the c alled  trunk g roup  (one of the 
field s 4 - 13) matc hing  the p resented  b earer c ap ability of the 
c alling  extension or trunk d etermines how the c all is treated, as 
follows:
— If the field  is 0
 the c all is switc hed  to the c alled  trunk g roup .
— If the field  is 1
 a mod em p ool memb er is inserted  and  the c all 
is switc hed  to the c alled trunk g roup .
NOTE:
Modem pool decisions are ignored for 
extension-to-extension, trunk-to-trunk, and  
trunk-to-p referenc e c alls.
— If the field  is 2
 the c all is b loc ked  with interc ep t treatment. 
						

							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-50 ISDN PRI Layer 3 
5
nThe information typ e (restric ted  or unrestric ted) of the c alling  
extension or trunk is p resented  to the c alled  trunk g roup. This 
information typ e is d erived  in d ifferent ways d epend ing  on the c all 
type as follows:
— For a c all from a non-ISDN extension or trunk to a trunk 
g roup , the information typ e of the c alling  extension or trunk, 
taken from BC COS field  15 of the c alling extension or trunk, 
is p resented  to the c alled  trunk g roup .
— For a c all from an ISDN extension or trunk to a trunk g roup , 
the information typ e, d erived  from the b earer c ap ability 
information element of the ISDN messag e, is presented  to 
the c alled  trunk group .
nThe c alled  trunk g roup s information typ e, taken from field  3 of the 
c alled  trunk g roup s BC COS, is c omp ared with the information typ e 
of the c alling  extension or trunk. Dep end ing  on these values, the 
following  ac tions are taken:
— If the information typ e of the c alling  extension or trunk is restric ted  
and  field  3 of the c alled  trunk g roup is 1
 (unrestric ted ), the c all is 
allowed.
— If the information typ e of the c alling  extension or trunk is 
unrestric ted  and  field  3 of the c alled  trunk g roup is 0
 (restric ted ), 
the c all is b loc ked  with interc ep t.
— If the two information typ es matc h, the c all is allowed . Note that 
even if the call is allowed , you must still make sure the transmission 
fac ilities the c all will use are ind eed what is ad ministered . For 
examp le, if you have unrestricted
 ad ministered  b ut the d ig ital d ata 
c all is mad e over restric ted  transmission fac ilities in the network, 
the d ata will b e c orrup ted .
3. Extension or Trunk Calling  Trunk Group  Using  AAR/ARS Routing  Pattern 
Preferenc e
The following  list d esc ribes the BC COS operation when a trunk or 
extension c alls an AAR/ARS routing  p attern preferenc e in the system:
nThe b earer c ap ab ility of the c alling  extension or trunk is p resented  
to the called preference. This bearer capability is derived in 
d ifferent ways d ep end ing  on the typ e of c all as follows:
— For a c all from a non-ISDN extension or trunk to a 
p referenc e, the b earer c apab ility, taken from BC COS field  
16 of the c alling  extension or trunk, is p resented  to the c alled  
p referenc e.
— For a c all from an ISDN extension or trunk to a p referenc e, 
the bearer capability, derived from the bearer capability 
information element and low-layer c ompatibility information 
element (if p resent) of the ISDN messag e, is p resented  to 
the c alled  p referenc e. 
						

							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-51 ISDN PRI Layer 3 
5
— For a d ig ital d ata c all, lac king the low-layer c omp atib ility 
information element, from an ISDN extension or trunk to a 
p referenc e, the b earer c apab ility p resented  to the c alled  
p referenc e is mod e 2.
— For a c all from a non-ISDN extension or trunk, having b earer 
capability of unknown digital
, to a preferenc e, the b earer 
c ap ab ility presented  to the c alled  p referenc e is the c alled  
p referenc es b earer c ap ab ility taken from its BC COS field  
16.
NOTE:
If a p referenc e is not assigned  a BC COS it d efaults to 
the BC COS assigned  to the trunk g roup  assoc iated  
with the preference.
nThe value in the BC COS field  of the c alled  p referenc e (one of the 
field s 4 - 13) matc hing  the p resented  b earer c ap ability of the 
c alling  extension or trunk d etermines how the c all is treated, as 
follows:
— If the field  is 0
 the c all is switc hed  to the c alled  p referenc e.
— If the field  is 1
 a mod em p ool memb er is inserted  and  the c all 
is switc hed  to the c alled preferenc e.
NOTE:
Modem pool decisions are ignored for 
extension-to-extension, trunk-to-trunk, and  
trunk-to-p referenc e c alls.
— If the field  is 2
 the c all is b loc ked  with interc ep t treatment.
nThe information typ e (restric ted  or unrestric ted) of the c alling  
extension or trunk is p resented  to the c alled  preferenc e. This 
information typ e is d erived  in d ifferent ways d epend ing  on the c all 
type as follows:
— For a c all from a non-ISDN extension or trunk to a 
p referenc e, the information typ e of the c alling  extension or 
trunk, taken from BC COS field  15 of the c alling  extension or 
trunk, is presented to the called preference.
— For a c all from an ISDN extension or trunk to a p referenc e, 
the information typ e, d erived  from the b earer c ap ability 
information element of the ISDN messag e, is presented  to 
the c alled  p referenc e.
— For a mod e 0, mod e 3, or mode 3/2 ad ap tive c all from a 
non-ISDN extension or trunk to an ISDN preferenc e, the 
information typ e from field  15 of the BC COS of the c alling  
extension or trunk is used  to b uild  the ISDN messag e. 
						

							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-52 ISDN PRI Layer 3 
5
NOTE:
For any call to an ISDN preference requiring a modem 
p ool memb er, the BC COS of the trunk g roup 
assoc iated  with the analog  half of the mod em pool is 
used  to b uild  the outgoing ISDN messag e.
nThe c alled  p referenc es information typ e, taken from field 3 of the 
c alled  p referenc es BC COS, is c ompared  with the information typ e 
of the c alling  extension or trunk. Dep end ing  on these values, the 
following  ac tions are taken:
— If the information typ e of the c alling  extension or trunk is 
restric ted  and  field  3 of the c alled  p referenc e is 1
 
(unrestric ted ), the c all is allowed .
— If the information typ e of the c alling  extension or trunk is 
restric ted  and  field  3 of the c alled  trunk g roup  is 0
 
(unrestric ted ), the c all is b loc ked  with interc ep t.
— If the two information typ es matc h, the c all is allowed . Note 
that even if the c all is allowed , you must still make sure the 
transmission fac ilities the call will use are indeed what is 
ad ministered . For examp le, if you have unrestricted
 
ad ministered  b ut the d ig ital d ata c all is mad e over restric ted  
transmission fac ilities in the network, the d ata will b e 
corrupted.
NOTE:
All international d ig ital data c alls should  b e administered  as information 
typ e unrestric ted .
The following  list d esc rib es a sug g ested  method  for d efining  BC COSs and  
assig ning  them to extensions, trunk g roup s, and  routing  p referenc es:
NOTE:
Field s 2 and  14 of proc edure 014, word  1, are not used  at this time.
1. For eac h objec t (extension, trunk g roup , and  p referenc e) in the system, 
list eac h b earer c ap ab ility you want that ob jec t to ac c ep t and  whic h ones 
you want b loc ked  on inc oming  c alls to that ob jec t.
2. Assig n trunk g roup  BC COSs b efore p referenc es. This is bec ause if a 
p referenc e is not assig ned  a BC COS, c alls will still b e allowed  b ec ause 
the p referenc e will use the assoc iated  trunk g roups BC COS as a d efault.
3. For eac h b earer c ap ab ility you want ac c ep ted  in an inc oming  c all to an 
ob jec t, list whic h ones should  b e switc hed  d irec tly to the ob jec t and  whic h 
ones should  have a mod em inserted  b efore b eing  switc hed .
4. Make a map  of c onnec tivity between all the ob jec ts. For examp le, for a 
g iven routing  p referenc e, a list of all the extensions and  trunk g roup s that 
c an c all that p referenc e should  b e formed . 
						

							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-53 ISDN PRI Layer 3 
5
5. Using  this map  and  the rules from BC COS Operation above, note any 
sp ec ial c onsid erations when inc oming  c alls orig inate from the c onnec ted  
ob jec ts. For examp le, if a p artic ular routing  p referenc e is to c irc uit switc h 
c alls from an ISDN trunk group  that will b e rec eiving  d ig ital data c alls 
lac king  low-layer c omp atib ility, the p referenc es BC COS must b e d efined  
to c irc uit switc h mod e 2 b earer c ap ab ility b ec ause that is what will b e 
p resented to the p referenc e. 
6. Based  on the ab ove analysis, assig n a p red efined BC COS to eac h 
ob jec t. For any g iven ob jec t, p ic k a pred efined BC COS that most c losely 
matc hes the inc oming  c all req uirements from the p revious step s b ut that 
also matc hes the inc oming  req uirements of the other ob jec ts to whic h it 
will c all. For examp le, if the inc oming req uirements are satisfied but the 
ob jec ts information type is c lear and  it will b e c alling  a restric ted  trunk 
g roup , some fields will need  to be c hang ed .
— If one of the p re-d efined  BC COSs for an ob jec t d oes not matc h 
these req uirements, make a c op y of the one that most c losely 
matc hes the req uirements.
— Define a new BC COS (not in the rang e 0 to 8) in p roc ed ure 014.
— Chang e the field s in this new BC COS to satisfy the requirements.
— Assig n this new BC COS to the ob jec t.
— Continue this p roc ed ure until all ob jec ts have b een assig ned a 
suitab le BC COS.
7. For BC COSs assig ned  to trunk g roup s or preferenc es that are either 
mod em p ool or host ac c ess trunk g roup s, c omp lete p roc ed ure 014, word 
2.
Traveling Class Mark (TCM) I
All DEFINITY systems p op ulate the TCM IE, whic h is sent in the SETUP messag e 
in either c od eset 6 or 7, with the fac ility restric tion level (FRL) of the c all. The TCM 
IE is not p op ulated  until the FRL of the c all is d etermined . For examp le, if an 
authorization c od e is entered  at the orig inating  switc h, the TCM IE is p op ulated  
with the FRL resulting  from the entered  c od e. If an authorization c od e is 
p romp ted for b y a switc h other than the orig inating  switc h, the resulting  FRL will 
p opulate the TCM for the outg oing  c all from that switc h.
G3V2 systems d o not p op ulate the satellite hop c ounter oc tet or the end -to-end  
ISDN ind ic ator oc tet. G2.2 systems p op ulate the satellite hop  c ounter oc tet with 
the c urrent value of the c ounter. G2.2 systems p op ulate the end -to-end  ISDN 
id entifier from the ad ministered value in p roc ed ure 010, word  4 field 3. You c an 
req uest that a c all b e sent only over ISDN PRI trunk group s, over ISDN PRI trunk 
g roup s if they are availab le otherwise over any trunk g roup , or over non-ISDN PRI 
trunk g roup 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-54 ISDN PRI Layer 3 
5
NOTE:
In the inc oming  d irec tion, if this field  is set to ISDN exc lusive or ISDN 
p referred  and the G2.2 rec eives a TCM IE ind ic ating  ISDN fac ilities 
exc lusive or p referred , the G2.2 will not p rovide answer tone on a d ata c all.
Temporary Signaling Connections
Another c ap ab ility of user-to-user information sig naling, c alled  temporary 
sig naling  c onnec tion (TSC), allows two ISDN PRI end p oints to exc hange 
user-to-user information (such as the data in a DCS message) in messages not 
assoc iated with establishing or tearing down a particular c all. In normal signaling 
c onnec tions, user-to-user information c an b e passed  end  to end  in c all 
estab lishment and c learing messag es (SETUP, ALERTing , CONNec t, and  
DISConnect). This is called messag e-associated  user-user (MA UUI) signaling . 
The AT&T network, however, b eing  c onc erned  ab out resourc es for transp orting  
larg e q uantities of user-to-user information, c ould  not g uarantee end -to-end  
d elivery of MA UUI information in these messag es. To hand le this typ e of servic e, 
the network estab lished  TSCs, in whic h user-user information is sent in a sp ec ial 
messag e (USER INFOrmation). The user req uests the TSC from the network in a 
messag e. After the TSC is set up, the two end s exc hang e information in the 
USER INFOrmation messag es until the TSC is torn d own. TSCs are p resently 
used  to exc hang e user-to-user information sup p orting  the DCS and  DCS-AUDIX 
features in whic h the DCS messag es are transp orted  over the D c hannel.
Two typ es of TSCs exist, c all-assoc iated  TSCs (CA-TSCs) and  
non-c all-assoc iated  TSCs (NCA-TSCs). In CA-TSCs, user-user information c an 
b e exc hang ed  at any time b etween when the c all has b een estab lished to when it 
is torn d own. In NCA-TSCs, user-user information c an b e exc hang ed without an 
assoc iated  c all b eing  set up  on a B c hannel. In this c ase, the NCA-TSC is 
req uested in a SETUP messag e in the c hannel ID IE. A c od epoint in the c hannel 
ID IE (the D c hannel ind ic ator) allows you to sp ec ify that the id entified  c hannel is 
a D c hannel, indic ating this is a D c hannel c all. User-user information c an then 
b e exc hang ed  until one sid e dec ides to send  a RELease messag e, at whic h time 
the NCA-TSC is c leared. For the DCS and  DCS AUDIX features imp lemented  
over the D c hannel, NCA-TSCs are used  to transp ort some of the DCS messag es 
(CA-TSCs are also used  for some DCS messag es). Bec ause of the way stand ard  
DCS was imp lemented  (over X.25 virtual c irc uits), the NCA-TSCs must b e 
ad ministered . This is b ec ause D c hannel DCS still req uires the c onc ep t of a 
virtual c irc uit (a logic al c hannel on an X.25 link). Thus, the NCA-TSCs are 
ad ministered  on the sig naling  g roup  form. You c an estab lish the NCA-TSC either 
p ermanently or on an as-need ed  b asis. In a p rivate network, the TSC should  b e 
estab lished  p ermanently whereas if the TSC is g oing  over the pub lic  network, 
suc h as SDN servic e, it should  b e established  on an as-need ed  b asis to save the 
c ost of the servic e.
Implementing TSCs in G3V2 Systems
For d etails on how to imp lement TSCs in G3V2 systems, refer to the DCS over the 
ISDN PRI D c hannel sec tion in the 
Imp lementation manuals for G3rV2 and  G3iV2. 
In g eneral, NCA-TSCs in G3V2 systems work as follows: