Project

General

Profile

Feature #3285

design + implement tools to analyze inter-PCU cell changes

Added by laforge 3 months ago. Updated 13 days ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Start date:
05/23/2018
Due date:
% Done:

0%

Estimated time:
Spec Reference:

Description

Following-up from #3284:

Maybe a good start would be some brainstorming on the kind of logging or log processing we'd have to do in order to properly analyze this.

Maybe we even should send the occasional PACKET MEASUREMENT ORDER to the MSs so we get their view on actual measurement values even in packet transfer mode?

That should allow us to plot per-MS graphs on their view of neighbor cells over a time line.


Related issues

Related to OsmoPCU - Bug #3284: GPRS cell re-selection appears sticky in packet transfer / packet idle modeNew2018-05-23

History

#1 Updated by laforge 3 months ago

  • Related to Bug #3284: GPRS cell re-selection appears sticky in packet transfer / packet idle mode added

#2 Updated by laforge 3 months ago

daniel: Could we create test scenarios for the NG40 RAN simulator which would simulate inter-PCU cell re-selection towards the SGSN? The idea would be to simulate a number of PS-attached MS, which then move around the network, causing the MS to move from one simulated PCU to other simulated PCUs.

The Implementation under Test (IUT) would be OsmoSGSN in this case, with OsmoHLR + OsmoGGSN in place to make it operational.

#3 Updated by laforge 13 days ago

laforge wrote:

daniel: Could we create test scenarios for the NG40 RAN simulator which would simulate inter-PCU cell re-selection towards the SGSN? The idea would be to simulate a number of PS-attached MS, which then move around the network, causing the MS to move from one simulated PCU to other simulated PCUs.

daniel ping? Any news on this? Thanks!

#4 Updated by daniel 13 days ago

I think a test like [2G_M2CN_RAU(2G)] (and similar) should already be doing this. This test case is in callscenarios_2g_3g.conf on alice in the config/sysmocom-ran/ directory.

The scenario looks like this:

BEGIN_SCENARIO  = attach -1 $area_groups[0] $atttype 0, wait tp1,
                  activate 0 0, wait tp1,
LOOP_SCENARIO   = updtarea $area_groups[0] $rautype, wait tp1,
END_SCENARIO    = deactivate 0, wait tp1,
                  detach 0 0

The update happens in updtarea and area_groups0 includes the tree cells that are configured for 2G and I believe it cycles through them. It's also possible to pass -22 in order to stay on 2G or (I think) specify the area explicitly by number.

I have added a test with the same name to our regular callscenarios.conf file there

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)