Sunteți pe pagina 1din 9

Ericsson RNC IuPS (ATM) Migration Procedure

1. Preparation

1.1 Prerequisites data needed

1.1.1 RNC Port allocated for IuPS link connection (i.e MS-6-4)
1.1.2 SGSN Data:
- SGSN Signalling Point Code
- SGSN ATM Address
- Vp and Vc ATM planning

Sample as below:

PDR Creation IP ATM

PDR PDR Creation IP (RNC) (SGSN) VcID Class
1 40 UBR
2 41 UBR
3 42 UBR
4 43 UBR

SGSN Point Code 9607

Add Information 919413099995

vp ID ATM PCR Class
Vpltp port 2 322000 CBR

Vcltp for Vc ID ATM PCR Class Remark
PDR-1 40 UBR
PDR-2 41 UBR
PDR-3 42 UBR
PDR-4 43 UBR
Signaling 36 P4500M3000 UBR+ slc = 1
1.2 Collecting RNC dump for current configuration


1.3 Collecting logs before activity

l+ $nodename_Before_IuPS_Migration.log

lt all








1.4 Collecting Last 24 hours rncpmrperformance data

l+ $nodename_Before_Activity_Performance.log

pmr –r 3 –m 24


2. Migration Activity

Create new startable CV before migration activity


2.1 Delete existing configuration

l+ $nodename_Iups_ATM_migration_activity.log

lt all



u+ Delete_Existing_IuPS




it will create a script in case of fallback needed. Script is stored in your current moshell working directory

<current_moshell_directory>/ Delete_Existing_IuPS.mos

2.2Load prepared configuration script


Script sample:

Summary of creating new IuPS link as below:

Common Configuration

- Create new AtmPort

- Create new Vpltp
- Create new VpcTp

UserPlane configuration

- Create Vcltp for PDR

- Create Aal5 for PDR
- Create PacketDataRouter

ControlPlane configuration

- Create Vcltp for signaling

- Create Aal5 for signaling
- Create NniSaalTp
- Create Mtp3bSrs
- Create Mtp3bSls
- Create Mtp3bSlItu
- Create Mtp3bSr
- Create Mtp3bAp
- Create SccpApRemote
- Create SccpEntitySet
- Create SccpGlobalTitle
- Create Ranap

Notes: For migration we don’t need to create Iulink MO for PS since we will use the existing. In case the
userplane is different (i.e migrating from SGSN ATM to SGSN IP) then we need to delete existing and
create new Iulink MO for PS.

2.3 Verification

Make sure all below MOs are unlocked and enabled

lt all




Check all pdr status is OK

Lh mod drh_pdrrh

Confirm no active alarms related with the activity


Create new startable CV after activity complete


Closed the activity log


2.4 Performance check for 15 minutes clear rop after migration

pmr –r 3 –m 0.25

3. Fallback scenario

l+ $nodename_Fallback_Iups.log

lt all



Delete the configuration



Load the fallback script prepared by undo script. See end of section 2.1

run <current_moshell_directory>/ Delete_Existing_IuPS.mos

Verify all configurations is restored

lt all




Lh mod drh_pdrrh



Other useful commands

Checking the pdr status

lh mod drh_pdrrh

Restart the pdr

acc001900/sp0.lnh restart restart pdrspb slot-19

acc002000/sp0.lnh restart restart pdrspb slot-20

acc002100/sp0.lnh restart restart pdrspb slot-21

acc002200/sp0.lnh restart restart pdrspb slot-22

acc002300/sp0.lnh restart restart pdrspb slot-23

Checking the data volume send by RNC to SGSN

For non-Hs last 1hour

PmxrncpmSentPacketData1|pmSentPacketData2|pmSentPacketData3|pmSentPacketData4 –m 1 -a

For HS last 1 hour

PmxrncpmSentPacketDataHs –m 1 –a
Note: Data unit is in kByte

Troubleshooting case found during migration

1. Pdr sending no resource available


IuPS migration is done. All requirements are configured properly both sides. We can check the status
as below:
But many UEH_EXCEPTION from rnc showing exceptionCode = 20 and 941, informing no resource
available in pdr.
[13:51:55.300]0014 (UEH_EXCEPTION) ../src/UehRabHandlingC.cpp:6850
TRACE1:ExceptionCode = 20; Received signal setupRabRej on DrhIfPdrRhP;
FailureIndication; DRH; RRCConNotRel; No affect on connection; RabHandling; UeRef =
531; IMSI = 404591130661184; cellId = 1073; cellFroId = 89; S-RNTI = 16915; connType =
uehRrcConn; sGCP=00000000; targetConnType = uehPacket38464; tGCP=00000000;
PdrHandling,PdrSpConfiguration:WaitForRabSetupCfm:setupRabRej; causecode = 301;
[13:51:55.300]0014 (UEH_EXCEPTION) ../src/UehGenRabEvaluationD.cpp:6042
FailureIndication; UEH; RRCConNotRel; Rab Assignment Eval fails; GenRabEvaluation
function evaluateRetryAttempt; UeRef = 531; IMSI = 404591130661184; cellId = 1073;
cellFroId = 89; S-RNTI = 16915; Current connType=uehRrcConn; sGCP=00000000; Target
connType=uehNotValid; causecode=114; createReconfReqForRetry set reconfResult to 0

Cause code=301 isdrhPdrRh_noResources: There are no resources available to execute the request.

Checking pdr usage is low but status is NOK

User will experience very difficult to access PS service. From DT team report, it is only 1 success from 12
attempts made.

We suspect media transmission problem with delay and low ping success rate measured by pdr device.

The PDR RH has no knowledge of the bandwidth of the different IuLinks, and therefore there is a risk
that it will allocate RABs on IuLinks that are overloaded and this will cause a lot of dropped packets for
RABs that are using this IuLink.

To avoid overloading the IP over ATM IuLinks PDR will constantly supervise
the load on these links, and whenever such an a link is considered overloaded no more RAB:s will be
allocated on that specified IuLink.

The current IuLink load is estimated using two factors:

• Delay: the average delay for how long it takes for an ICMP ping to be answered.
• Number of unanswered ping requests: the number of unanswered ping requests during a certain timer
period is calculated.
Whenever a link is considered overloaded PDR reports this to the PDR RH, provided that a PDR RH is
allocated. As a consequence the PDR RH will not allocate any more RABs on this IuLink, until the IuLink is
no longer overloaded. PDR will send information to the PDR RH when it no longer considers the IuLink to
be overloaded.

To check if overload happens in pdr we activate below traces:

Lhpdrte e trace1 SP_MEAS

Lhpdrte e trace1 SP_OVERLOAD

Check the trace result with command lhpdrter, and we found below information. Iulink is in overload
situation and will not allocate RAB for new request until it leaves the Overload state. Overload state due
to ping success rate is below minimum ping success rate allowed.

0020SP0: [2014-03-28 09:36:16.487] PDRMUX_server(SP_OVERLOAD)

pdrPdrmuxIuLinkLoadHandler.cpp:389 TRACE1:[instanceId -1 ], IuLink enters state overloaded,
linkLoadStatusInd sent, froId: 1, pingSuccessRate: 33 % <pingMinSuccessRateCfg: 66%, or
pingAverageDelay: 666 ms>PMaxD: 1050 ms, ingHighestVariationDelayRatioCfg: 200 %PMinD = 500 ms,
PMaxD = 1050 ms

After media transmission stable, we check that Iulink leaves overload state and pdr status become OK.
UEH_EXCEPTION Code = 20 and 941 are not occurring anymore. Testing on field all attempts success
with speed download 3~4 Mbps.

2. IuPs signaling intermittently down

Alarms log showing Iu PS signaling is fluctuating, intermittently down

PS Iu signaling showing very low success rate. Check with pmr –r 3

User will experience difficult to access new PS service connection. Existing calls/service will be
maintained until sccpApRemote=ps disabled for more than 100 seconds and all connection will be
released by systems.

Escalate the issue to transmission team to check.