PABX workshop

Background Information on PRA in

MSS
With the PRA feature, the Private Automatic Branch
Exchanges (PABXs) and other equipment are
connected to M-MGw using Primary Rate interfaces
(30 B-channels and a D-channel).
The D-channel (PABX call control) messages are
exchanged with Q.931 protocol (backhauled on the
IUA/SCTP/IP stack).
B-channels (PABX speech channel) are controlled
from the MSC-S BC over the (existing) GCP interface
to M-MGw.
 PRA in MSS

The SGw function in M-MGw backhauls DSS1 (Q.931) circuit

switched call control signaling between PBXs and conventional
MSC-S or MSC-S BC.

The MSC-S node controls the switching of the B-channels over

Gateway Control Protocol (GCP). The M-MGw will transport the
B-channels towards other networks or nodes.
MSC-S SGW/M-MGw PBX
NIF
Q.931 Q.931

IUA IUA LAPD

LAPD LAPD
Q.921 Q.921
SCTP SCTP

IP IP TDM TDM

IP TDM
 PRA in MSS
The PBXs and the M-MGw exchange the DSS1 signaling
information over ETSI standard ISDN access interface based on
LAPD.
The M-MGw and the MSC-S node exchange the DSS1 signaling
information over IETF standard backhaul protocol, IUA.
The SGw function in the M-MGw enables the mapping
between TDM and IP based signaling for Q931.
The PRA D-channels terminated in the M-MGw will be
identified by means of Interface Identifiers (IIDs) between the
M-MGw and the MSC-S node.
One IID corresponds to one PRA D channel with LAPD
signaling.
PRA solution for MSC-S

transport layer
network layer
link layer
PRA solution in BC
 PRA solution in BC
The managed objects related to PRA functionality, and remote
TDM circuits in particular, will be configured at the SPX. All
PRA accesses will be connected to only one SPX.
A dedicated virtual MGW that owns PRA access lines is
configured in each M-MGw.
The SPX will be in control of these virtual MGWs and their
TDM devices and will have a dedicated GCP signaling relation
to the corresponding vMGW in each M-MGw.
There are two SPXes in the MSC-S BC architecture in order to
provide redundancy. This redundancy does not apply to PRA,
since a PRA can only be served by one SPX.
PRA to PRA calls can be completely handled in the SPX, while
PRA from/to other access (MS/UE/Trunk) have to pass MSC
blades. Link between SPX and MSC blades is handled by
INTRO running over SCCP/M3UA.
PRA Implementation in M-MGw
Detailed SPX definitions
Relation between managed objects for ISDN signalling
in conventional MSC-S or MSC-S BC and M-MGW

1:1
IID 0

Interface Interface
0

IuaLocalEndpoint
DChannelTp

GPB

IuaAssociation
IID 1

IP
IUA DChannelTp 1

SAID
IID 2

EPID
Signaling 2
DChannelTp
Destination

GPB
(DEST)

IP
IID N 1:N
N:1 DChannelTp N

Sctp
M-MGw

IID 0 1:1 DChannelTp 0

IuaLocalEndpoint
GPB

IuaAssociation
IID 1
IUA DChannelTp 1
SAID

IID 2
EPID

Signaling DChannelTp 2
Destination

GPB
(DEST)

IID N N
DChannelTp

Sctp
M-MGw

MSC-S
 Managed objects related to PRA
functionality
• SCTP End Point
– An SCTP End Point (EP) object represents the SCTP EP
as used by the IUA.
– An SCTP EP is created with command IHBII and
deleted with command IHBIE.
• SCTP Association
– An SCTP Association object maintains the SCTP
Association states and initiates SCTP procedures. An
SCTP Association used for IUA is always tied with an
IUA Signaling Association in a one-to-one relation.
– An SCTP Association is created with the command
IHADI and deleted with the command IHADE.
 Managed objects related to PRA
IUA
functionality
ISDN User Adaptation Layer

• IUA Signaling Association

– The IUA Signaling Association object maintains the IUA
states and procedures. It is identified with the same
association identity as the connected SCTP
Association.
– The IUA Signaling Association is implicitly created in
the same command for creating the SCTP Association
(IHADI). The IUA Signaling Association object is
deleted, when the SCTP Association is deleted, with
the command IHADE.
– Detailed SPX definitions
 Managed objects related to PRA
functionality
• IUA Signaling Destination
– The IUA Signaling Destination object is the IUA
representation of the remote IUA SGW.
– The object is created by the command ULSDI and deleted
with the command ULSDE.
• MGW
– MGW is the object representing remote MGW to which
the MSC-S is connecting by GCP and where PRA
terminations reside. The object is defined and associated
with the Bearer Control Unit Identifier (BCU-ID). MGW is
defined with command NRGWI and deleted with
command NRGWE.
• Detailed SPX definitions
Real data for TELCEL (NEXTENGO SPX1)
<ULSDP:DEST=ALL;
USER ADAPTATION LAYER SIGNALLING
DESTINATION DATA

DEST PROT DSTATE

XOCMGB IUA AVAIL
POPMGB IUA AVAIL
NEXMGA IUA AVAIL

END
 Managed objects related to PRA
functionality
• MGG
– MGG represents the MGW Group in which the
MGW is included that hosts the PRA.
– It is created with command NRGGI and deleted
with command NRGGE.
• Connection of restricted MGG to PRA is done
by command IUMGI.
– IUMGI:DEV=LIPRRGS-x,MGG=PBXMALMOE;
• Detailed SPX definitions
 Managed objects related to PRA
functionality
• E-SNT
– E-SNT represents the TDM termination group in
the MGW.
– It is connected to the MGW object by command
NTCOI.
• Detailed SPX definitions
<NRGGP:MGG=all;
MEDIA GATEWAY GROUP DATA

MGG MG RESTRICTED DEFAULT MISC MGP WF

GXOM1S1 XOCMGB RESTRICTED

GPOM2S1 POPMGB RESTRICTED

GNEM1S1 NEXMGA RESTRICTED

END

<NRGWP:MG=all;
MEDIA GATEWAY DATA

MG BCUID STATUS MGG MGS INFO MC

XOCMGB 288 AVAIL GXOM1S1 ITUMTP 0
3-288

POPMGB 586 AVAIL GPOM2S1 ITUMTP 0

3-586

NEXMGA 485 AVAIL GNEM1S1 ITUMTP 0

3-485

END
 Managed objects related to PRA
functionality
• PRA Device
– PRA Device object represents the ISDN-E devices used
for PRA. One of the devices is a PRA signaling device,
which corresponds to a D-channel, the others are PRA
bearer devices, each corresponding to a B-channel.
– PRA bearer devices are connected to the E-SNT by
command EXDUI.
– The PRA signaling device is connected to Interface
Identifier (IID) with command EXUAI.
• Detailed SPX definitions
<ntcop:snt=all;
SWITCHING NETWORK TERMINAL CONNECTION DATA

SNT SNTV DEV EXTP

MG
RTDMA-5951 2 LIPRRMG-6336&&-6367 2-2-226221
NEXMGA

DIP
1GAMGS

SNT SNTV DEV EXTP

MG
RTDMA-5953 2 LIPRRMG-6400&&-6431 2-2-226239
NEXMGA

DIP
3GAMGS
Definition of INTRO Route between SPX and
MSC Blades
– The INTRO route has to be defined with the SPCs defined in previous
steps.
– The INTRO route is created by command EXROI. The device owner is
INTRO.
– Route data of an existing INTRO route is changed by command EXRBC.
– Special definition of INTRO route has to be applied for PRA in MSC-S
BC call handling. The INTRO route has to be defined as outgoing route
only. No incoming INTRO route shall be defined. Since parameter BLAO
is not supported in outgoing INTRO route, default INTRO incoming
route is automatically used for PRA traffic.
– Since always the default incoming INTRO route is used by PRA call, B-
Number Origin (BO), Charging Origin (CO), Route Origin (RO) are not
modified by incoming INTRO route parameter settings. BO, CO, RO
which are carried by IAM in originating MSC Blade or SPX are kept.
– For more details refer to Application Information for block INTRO.
Real data for TELCEL (NEXTENGO SPX1)
<exrop:dety=intro;
ROUTE DATA
R ROUTE PARAMETERS
SP1BC1O DETY=INTRO FNC=1 OBJECTID=

GENERIC PARAMETERS IN ROUTE OWNER

SPXNI=3 SPXSPC=13572 BLDNI=3
BLDSPC=499

END
SP SPID NET PREF MODE
2-13572 OWNSP NEXBX1
3-13572 OWNSP NEXBX2
3-499 NEXBC1 IP NOACT
 NEXTENGO SPX2
C:\>mml -cp CP2
<c7spp:sp=all;
CCITT7 SIGNALLING POINT DATA

SP SPID NET PREF MODE

2-13573 OWNSP NEXBX2
3-13573 OWNSP NEXBX2
3-499 NEXBC1 IP NOACT
 In the BC
<exrop:dety=intro;
ROUTE DATA
R ROUTE PARAMETERS
BC1SP1O DETY=INTRO FNC=1

GENERIC PARAMETERS IN ROUTE OWNER

SPXNI=3 SPXSPC=13572 BLDNI=3
BLDSPC=499

END
 In the BC
CCITT7 SIGNALLING POINT DATA

SP SPID NET PREF MODE

3-498 OWNSP NEXBC1
3-499 OWNSP NEXBC1
3-13572 OWNSP NEXBX1
3-13572 NEXBX1 IP NOACT
 alta y baja de PBX
1. Print out all data which will be needed for re-connection of PRA.

• Use the next printouts for data collection:

– IUPBP:PBX=ALL;

– IUPHP:PBX=pbx! It will show hunt group data;

– IUPVP:PBX=pbx! It will show number validation data;

– IUMGP:DEV=LIPRRMG-0! Time slot zero of the PRA. This will show this PRA access belongs to
which MGG (media gateway group);

– EXUAP:DEV=LIPRRMG-16!16th time slot on the PRA access. This will show the IID value and
the MGW.;

• If you suspect that more definitions have been done to the PABX, please check all
the IU printout commands. See atttached list Slide 46
 alta y baja de PBX
2. Block all device on the PRA access

– BLODI:DEV=LIPRRMG-1&&-15&-17&&-31;

3. Disconnect all affected LIPRRMG device from hunt group

– IUPHE:PBX=pbx,dev=LIPRRMG-1&&-15&-17&&-31,HG=hg;

4. Remove pbx validation data

– IUPVE:PBX=pbx,ANO=ano,L=l,AC=ac;
 alta y baja de PBX
5. Disconnect LIPRRMG devices from PBX

– IUPDE:PBX=pbx,dev=LIPRRMG-1&&-15&-17&&-31;

6. Disconnect 0 time slot from MGG and 16th

time slot from access gateway (MGW)
– IUMGE:DEV=LIPRRMG-0;
– EXUAE:DEV=LIPRRMG-16;
 alta y baja de PBX
7. Re-connect 16th time slot to access gateway

– EXUAI:IID=iid,DEV=LIPRRMG-16,DEST=dest_mgw;

8. Re-connect time slot zero to MGG

– IUMGI:DEV=LIPRRMG-0, MGG=MGGZ;

9. Connect LIPRRMG devices to the PBX

– IUPDI:PBX=pbx,dev=LIPRRMG-1&&-15&-17&&-31;
 alta y baja de PBX
10. Define PBX hunting group!

– IUPHI:PBX=pbx,dev=LIPRRMG-1&&-15&-17&&-31,HG=hg;
hg comes from step 1;

11. Define number validation

– IUPVI:PBX=pbx,ANO=ano,L=l,AC=ac;

12. De-block the LIPRRMG devices

– BLODE:DEV=LIPRRMG-1&&-15&-17&&-31;
 alta y baja de PBX
13. Print state of devices. They should be idle.

– STDEP:DEV=LIPRRMG-1&&-15&-17&&-31;
 ADJI & ADJO
IUS-AM
Originating Call
(ISDN-E) ADJI TRAM

Via APC-Link

Originating traffic
THE MAIN FUNCTION IN CP-PROGRAM ADJIU IS TO HANDLE THE INTERFACE
BETWEEN TRAM AND IUSAM. ADJI SUBSTITUTES DJI (SCS) BLOCK. ITS MAIN
TASK IS TO CONVERT THE OIP MESSAGES IN ISUP' FORMAT TOWARDS IUSAM
AND ISUP' MESSAGES IN OIP FORMAT TOWARDS TRAM.

R ROUTE PARAMETERS
DJI DETY=ADJI FNC=1 OBJECTID=
 ADJI & ADJO
IUS-AM
Terminating Call
(ISDN-E) TRAM ADJO

Terminating traffic
THE MAIN FUNCTION IN CP-PROGRAM ADJOU IS TO HANDLE THE
INTERFACE BETWEEN TRAM AND IUSAM. ADJO SUBSTITUTES DJO
(SCS) BLOCK. ITS MAIN TASK IS TO CONVERT THE OIP MESSAGES IN
ISUP' FORMAT TOWARDS IUSAM AND ISUP' MESSAGES IN OIP FORMAT
TOWARDS TRAM.

R ROUTE PARAMETERS
DJO DETY=ADJO OBJECTID=
 TEST SYSTEM trace in SPX
In this trace we are using MB(message buffer)
block to trigger the trace.
We will trigger the trace using the IA where the signal
MBPARASTORE is received in block MB.
For qualifying we use DR2 (Parameter Code in signal
MBPARASTORE )
For possible values of DR2 see reference text file attached.

The following trace is valid for all releases:

R13.0, R14.1, 12A, 12B, 13A, 14B, 15A, 16A.
3.3.4.1.2 SHORT PARAMETER
--------------------------
!
!>>>>>>>>>>>>>>>>>>>>>>>!
!>>> MBPARASTORE >>>!
!>>>>>>>>>>>>>>>>>>>>>>>!
! DATA STORED IN DATA REGISTERS - USED BY ASA SUBROUTINE !

RECEIVE MBPARASTORE FLINTERNAL MBP:FLCONNFIDMAIN WITH

MBP, ! MB POINTER !
TMBK, ! MB KEY !
TUSERP, ! USER POINTER !
TPARAMETER, ! PARAMETER CODE !
TMAXLENGTH, ! MAX LENGTH !
%, ! PARAMETER DATA LENGTH -USED IN ASA SUBROUTINE
!
%, ! PARAMETER DATA !
%, ! PARAMETER DATA !

----
%; ! PARAMETER DATA !

RECEIVE MBPARASTORE; 09DA

RSSU AR0- 14/ T0; (CFLSTATUS) 021E0E30 09DA
JUC AR0, 3, %L%11930; 09E078E6 09DC
 TEST SYSTEM trace in SPX
Depending on PBX setup A-num is usually sent as GN (group number)

Do IUSCP:SNB=xxxxxx to get appropriate number

IUSCP:SNB=<Subscriber Number>;

ISDN-E END USER DATA

SNB SNBTY DEV MIS

<Subscriber Number> 3 SI=1
UPDCN=4-1-<Subscriber Number>
PROTVAR
DSS1E

PROP

INDIVIDUAL LEVEL
OBA-n REFPNT-2 SUBGRP-33 TCP-1
 TEST SYSTEM trace in SPX
BSTY

INDIVIDUAL LEVEL
SPEECH AUDIO TPHY FAX23
FAX4 UDI UDITA

SSTY

INDIVIDUAL LEVEL
COLP
CLIP
CLIPRO
UUS1

END
 TEST SYSTEM trace in SPX
The calling party number is coming from a logical trunk (DJO, ADJO,
DJBGCO, etc) to MB. The element tag in D4 for calling party number is 7.
The calling party number starts in DR10, length and then digits from
DR11.
The Calling Party Number is stored in MHPRAE and IUNUMR as it is
received and then validated in LINV.
You could see the format of the signal by tracing it a couple of times:
ON IN MB MBPARASTORE;
ON IN DO: IF DR2=7,FOR 2 TIMES,P SWD,P IA,P EXECFID,;
PROGRAM TRACING (1)

ON INSIG
MB (B) COMBSIG LSN=H'026 MBPARASTORE ON THL
FROM IUNUMR (B) WITH
H'0000 000D, H'0000 0032, H'0000 004F, H'0000 0007,
H'0000 0010, H'0000 0010, H'0000 0004, H'0000 0001,
H'0000 0000, H'0000 0000, H'0000 0000, H'0000 000A,
H'0000 0004, H'0000 0004, H'0000 0009, H'0000 0009,
H'0000 0003, H'0000 0002, H'0000 0000, H'0000 0005,
H'0000 0000, H'0000 0000, H'0000 000F, H'0000 000F,
H'0000 000F
MB (B) IA H'09DA
MB (B) EXECFID=H'0000 37F0

END
 TEST SYSTEM trace in SPX
ON IA MB H'9DA;!MBPARASTORE received hunt for A-num (as GN) !
ON IA DO: IF DR2=7;
IF DR11 = 7;
IF DR12 = 0;
IF DR13 = 0;
IF DR14 = 3;
IF DR15 = 9;
IF DR16 = 1;
IF DR17 = 0;
IF DR18 = 2;
FOR 1 TIMES;
SET TVAR 0=EXECFID, STEPTVAR 0 PRINT, P IA, P EXECFID,;

The calling party number is coming from a logical trunk (DJO, ADJO, DJBGCO, etc) to MB. The
element tag in D4 for calling party number is 7.
The calling party number starts in DR10, length and then digits from DR11.
The Calling Party Number is stored in MHPRAE and IUNUMR as it is received and then validated
in LINV.
 TEST SYSTEM trace in SPX
ON IA MB H'9DA; ! MBPARASTORE received hunt for B-num !
ON IA DO: IF DR2=5;
IF DR8 = 7;
IF DR9 = 0;
IF DR10 = 0;
IF DR11 = 3;
IF DR12 = 9;
IF DR13 = 1;
IF DR14 = 0;
IF DR15 = 2;
FOR 1 TIMES;
SET TVAR 0=EXECFID, STEPTVAR 0 PRINT, P IA, P EXECFID,;
 TEST SYSTEM trace in SPX
ON VAR DO:IF TVAR 0=EXECFID;
IF TVAR 0 >0, P V, P IA, ;

ON OU DO:IF TVAR 0=EXECFID;

IF TVAR 0 > 0, P MS,P EXECFID,P IA,P SWD, ;

ON IN DO: IF TVAR 0=EXECFID;

IF TVAR 0 > 0,P MS,P EXECFID,P IA,P SWD, ;

ON IN MHPRAG;
ON OU MHPRAG;

ON VAR MHPRAG 403, 409, 410, 520; ! MESSAGESTATE MESSDATA MESSDIRECTION

TASKSTATE !

ON IN LITH, MPIH, LIPRRMG, IUTCC;

ON OU LITH, MPIH, LIPRRMG, IUTCC;
INIT;
 Another TEST SYSTEM trace in SPX
on fls do:if DR2=7,if dr10=10,if dr13=8,if dr14=1,if dr15=0,if
dr16=7,if dr17=9, …,if dr20=0,for 10 times,p swd,st,;
ON fls MB MBPARASTORE MBPARASTOREI;
on flin;
on flout;
ON FLIN DO:P MS,P IA,;
ON FLOUT DO:P MS,P IA,P SWD,;
ON VAR TRARE 4 9 39 273 316 131;

2) Verify the signals with SCCP Decoder.

ROUTEMSG ROUTEMSGI ROUTEMSGS ROUTEMSGE;
TAKEMSG TAKEMSGI TAKEMSGS TAKEMSGE;
 STS for ISDN
1. ISDNESG not giving counters on individual PRI [ Pilot
Numbers ].
2. All counters being pegged at SUBGRP-0.
– PROCEDURE:
Add ISDNESG object type :
1. stmotd –I
2. stmotd -a ISDNESG
3. stmotd –e
4. ISDNESG should turned to Yes in stmotls.
5. Define Report ID and MP ID
Define Report and include the object in Report.
stmrp PRI_SUB ISDNESG
 STS for ISDN
6. Insert Report with name of your choice :E.g. given below
stmmp -z LF -n PRISUB -b YYYYMMDDHHMM X abcd <-- Where abcd is
Report ID
7. All STS reports have default path :S:\Sts\data\Deliverydir\*.* and all the
Counter names can be seen with the help of command "stmotls -l ISDNESG“
ISDNESG object type has following counters:
NSCAN,SUBCNT,BSUBCNT,OTRALCNT,TTRALCNT,TCALLCNT,TSEIZCNT,TUCACNT
TANSCNT,TNUMLCNT,TBUSYCNT,TUSBUCNT,TRSERCNT
8. All pilot number should be assigned with different subgroup in its property so
that differentiation can be done in the reports for different PRI numbers.
9. Use IUSCC to change SUBGRP of individual Pilot PRI subscriber.
IUSCC:SNB=snb,PROP=SUBGRP-x;

Total 127 subgroup possible for ISDN PRI report which can be activated
and all the above counters can be seen under each SUBGRP attached in
subscriber property
References

Migration Guideline for PRA

from Non-Layered to
Layered for MSC Server Blade Cluster

Possible values for DR2

Parameter Code
in signal MBPARASTORE
References

IU commands list
alta y baja de PBX