With a minimal set of translations out of the way, I figured it was about time to get some trunking set up on the SL-100. My plan was to set up an ISDN PRI between the SL-100 and a Cisco ISR which would function as a tandem switch to connect between C*NET via asterisk, SCDP, and the PSTN.
I had a paper manual which I have scanned since then, DMS SuperNode System Primary Rate Interface (PRI) Translation, which I referred to.
I also had to spend some time wrapping some T1 cables down to the back of the LTC for the T1s I intended to use. I had that completed by the night of the 7th and started on the PRI trunking datafill on the night of the 8th.
As far as trunks go, ISDN is particularly complex involving over 10 different tables not counting the routing itself. Luckily, I had 298-7002-001 to follow which walked me through the basics of the datafill.
The first table to deal with is CARRMTC. There's a leftover entry from the university that looks like what I'll need:
CSPMTYPE TMPLTNM RTSML RTSOL ATTR
----------------------------------------------------------------------------
LTC ESFB8ZS 255 255 DS1 NT6X50AB MU_LAW ESF B8ZS BPV NILDL
N 250 1000 50 50 50 1000 3 6 864 100
17 511 4 255This is pretty close to the default entry for B8ZS and ESF, and it meets our needs, so we'll use it.
When we initially configured our LTC, we were just concerned with POTS and we didn't configure it to support DS1 trunks. We'll fix that by adding the correct EXECTAB entry for ISDN PRI.
LTCNAME
ADNUM FRTYPE FRNO SHPOS FLOOR ROW FRPOS EQPEC LOAD
EXECTAB
CSLNKTAB
OPTCARD
TONESET PROCPEC
EXTLINKS
E2LOAD
OPTATTR
PEC6X40 EXTINFO
----------------------------------------------------------------------------
LTC 0
1 LTEI 0 18 1 B 3 6X02NA QLI22AO
( POTS POTSEX) ( PRAB DTCEX)$
(0 10 16 0) (0 10 16 1) (0 10 16 2) (0 10 16 3) (0 10 16 4) (0 10 16 5)
(0 10 16 6) (0 10 16 7) (0 10 16 8) (0 10 16 9) (0 10 16 10) (0 10 16 11)
(0 10 16 12) (0 10 16 13) (0 10 16 14) (0 10 16 15) $
(UTR15 ) (MSG6X69 ) (CMR13 CMRU23A) (ISP 16) $
NORTHAA SX05AA $ SX05AA $
0
SXFWAL01
$
6X40FA NChanges to EXECTAB likely require, at the minimum, static data to be reloaded into the LTC.
We also need to assign a DS1 card within the LTC, which is done in LTCPSINV:
LTCNAME
PSLNKTAB
----------------------------------------------------------------------------
LTC 0
N (0 DS1PRA ESFB8ZS N 0 NIL $)
(1 DS1PRA ESFB8ZS N 0 NIL $) (2 DS1PRA ESFB8ZS N 0 NIL $)
(3 DS1PRA ESFB8ZS N 0 NIL $) (4 NILTYPE ) (5 NILTYPE )
(6 NILTYPE ) (7 NILTYPE ) (8 NILTYPE ) (9 NILTYPE ) (10 NILTYPE )
(11 NILTYPE ) (12 NILTYPE ) (13 NILTYPE ) (14 NILTYPE )
(15 NILTYPE ) (16 NILTYPE ) (17 DS30A ) (18 NILTYPE )
(19 DS30A ) $The syntax for one of the PSLNKTAB entries is as follows:
I set up 4 cards because each card is two DS1s, and also when I get to setting up clocking, the DMS will require that my primary and secondary clock sources be on different shelves, so I need one card provisioned (whether it's installed or not) in each shelf of my LTC.
We'll define the CLLI for our trunk group now. We've done this before for some tones back when we set up some treatments, so I'll just show the end result:
CLLI ADNUM TRKGRSIZ ADMININF
----------------------------------------------------------------
LBRDILLG01T0 100 24 PRI_TO_CISCOThe only new thing to note is the TRKGRSIZ actually matters here. This will be a PRI using the full T1, so it is 24 channels. Possibly the D channel isn't counted, and this could have been 23 instead.
The actual trunk group itself is then defined in TRKGRP.
GRPKEY
GRPINFO
----------------------------------------------------------------------------
LBRDILLG01T0
PRA 0 PRAC NCRT ASEQ N $ $While I'm using trunk group type PRA here, it's worth noting that there are other trunk group types which can be used for ISDN PRI. PRA is a fairly simple trunk group type, but in certain circumstances one of the more complicated ones may be applicable. At the very least, IBNT2 (two way IBN trunks) support ISDN using the LTID option to contain the LTID information.
If you remember back to configuring the first lines, PADGRP refers to PADDATA which controls the loss plan between difference line and trunk PADGRPs. I left this filled in with the defaults from the switch, which should be sane. PRAC is a good group for PRA trunks.
We will need an ISDNPARM to use with our trunk group. The ISDNPARM controls blocking of IEs as well as interactions with ISUP, it seems. There may be a DEFAULT entry (apparently not listed in the table) but I am not sure and I copied one of the old values from the university:
NAME MSGTYPE MSGDIR DFLTACT PARMACT
----------------------------------------------------------------------------
PRI1 SETUP BOTH MAP (DIE MAP) (SH5 BLK) (SH6 BLK) (SH7 BLK)
(UNK BLK) (CGS ATP) (CDS ATP) (LLC ATP)
(HLC ATP) $
PRI1 NOTIFY BOTH MAP (DIE MAP) (UNK BLK)$
PRI1 ALERT BOTH MAP (UNK BLK)$
TRKRCSEL is used to determine which ISDN IEs are used for routing characteristic selection. Individual IE types can be enable or disabled for determining the ISDN routing characteristics. The default behavior, if a TRKRCSEL is not defined (and defaults are used) is to use bearer capability and nothing else for routing characteristics.
This default behavior is fine by me, so I'm going to skip TRKRCSEL.
With those taken care of, we're ready to set up the trunk subgroup in TRKSUBGRP.
SGRPKEY CARDCODE
SGRPVAR
SGRPVAR
----------------------------------------------------------------------------
LBRDILLG01T0 0 DS1SIG
ISDN 10 12 87Q931 2 N YIELD USER PT_PT USER N UNEQ
75 Y PRI1 LTC 0 0 24 64K HDLC
$
$With the trunk subgroup created, we can create the trunk members.
CLLI EXTRKNM SGRP MEMVAR
-----------------------------------------------------------
LBRDILLG01T0 0 0 LTC 0 0 1
LBRDILLG01T0 1 0 LTC 0 0 2
LBRDILLG01T0 2 0 LTC 0 0 3
LBRDILLG01T0 3 0 LTC 0 0 4
LBRDILLG01T0 4 0 LTC 0 0 5
LBRDILLG01T0 5 0 LTC 0 0 6
LBRDILLG01T0 6 0 LTC 0 0 7
LBRDILLG01T0 7 0 LTC 0 0 8
LBRDILLG01T0 8 0 LTC 0 0 9
LBRDILLG01T0 9 0 LTC 0 0 10
LBRDILLG01T0 10 0 LTC 0 0 11
LBRDILLG01T0 11 0 LTC 0 0 12
LBRDILLG01T0 12 0 LTC 0 0 13
LBRDILLG01T0 13 0 LTC 0 0 14
LBRDILLG01T0 14 0 LTC 0 0 15
LBRDILLG01T0 15 0 LTC 0 0 16
LBRDILLG01T0 16 0 LTC 0 0 17
LBRDILLG01T0 17 0 LTC 0 0 18
LBRDILLG01T0 18 0 LTC 0 0 19
LBRDILLG01T0 19 0 LTC 0 0 20
LBRDILLG01T0 20 0 LTC 0 0 21
LBRDILLG01T0 21 0 LTC 0 0 22
LBRDILLG01T0 22 0 LTC 0 0 23Here, we simply define the 23 B-channels of our DS1 associated with the trunk.
Next, we declare a logical terminal group in LTGRP. There is a default LTGRP, 'ISDN', but it's not clear if we can just use that one.
GROUP GROUPNO OPTIONS
--------------------------
PRI 16 $PRIPROF defines profiles for ISDN protocol variants:
PROFNAME VARINFO
SWITCH
----------------------------------------------------------------------------
PROFPRI NIPRI NI2V1
(UNTONNPI)$Now we can define the logical terminal in LTDEF:
LTKEY LTAP
CLASSREF
----------------------------------------------------------------------------
PRI 1 B
PRA 23 NIPRI NI2V1 PROFPRI (NOPMD ) $The last bit of data entry we need for our ISDN PRI trunk is in LTMAP to assign the LTID to our trunk group.
LTKEY MAPPING OPTION
----------------------------------------------------------------
PRI 1 CLLI LBRDILLG01T0 ( TEI 0)$With the new entry in LTMAP, we can see that the DMS automatically updated the TRKGRP table as well:
GRPKEY
GRPINFO
----------------------------------------------------------------------------
LBRDILLG01T0
PRA 0 PRAC NCRT ASEQ N (PRI 1) $ $Another point we need to consider is clocking. Since the DMS isn't always on, I'm going to have it recover clock from the carrier for synchronization. Clocking synchronization is controlled through SYNCLK.
CLKKEY CLKDATA
OFFCDATA
-----------------------------------------------------
0 STRAT3
SLAVE LTC 0 0 0 LTC 0 2 1The format of the data in SYNCLK varies depending on how your office is clocked. In this example, I have set the clock as statum 3 slaved off of carrier trunks. Each trunk is specified by the peripheral identity, the circuit in that peripheral, and (for LTCs) the register on a two-link that gets used.
The DMS software requires you to set a secondary timing link and imposes some apparent requirements, presumably for redundancy reasons. At the very least, it seems to require that the carrier links be located in different shelves.
The DMS gets a bit picky here about the values it will accept, the only thing I can say is to use trial and error as the data schema manual doesn't seem to offer much help on the exact requirements.
With all of the datafill finally complete, now we need to put the trunk into service using MAPCI. When it is initially created, the trunk will be in the installation busy state (INB) and we will need to manually busy (BSY) and return to service (RTS) many individual parts like the trunk members, the D-channel, and the carrier. These are all separate elements because they get handled in different parts of MAPCI and aren't inherently associated to each other with any strict mapping.
Starting with the trunk, you can post it in MAPCI with 'MAPCI;MTC;TRKS;TTP;POST G LBRDILLG01T0'. You can move the trunks to manual busy with 'BSY ALL' and then put in service with 'RTS ALL'.
For the D-channel, similarly: 'MAPCI;MTC;TRKS;PRADCH;POST GD LBRDILLG01T0' followed by 'BSY ALL' and 'RTS ALL'.
And lastly for the T1 carrier itself: 'MAPCI;MTC;TRKS;CARRIER;POST LTC 0 0' followed by 'BSY ALL' and then 'RTS ALL'.
Since the clocking is set to track our new carrier, we may need to go ensure the clocking switches over to slave from the carrier in the message switch clock area of MAPCI. Unfortunately I didn't take specific notes on this.
The next step would be routing, but I'll leave that for the next post.