Project

General

Profile

Actions

Feature #3285

open

design + implement tools to analyze inter-PCU cell changes

Added by laforge almost 6 years ago. Updated about 3 years ago.

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

0%

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 modeNew05/23/2018

Actions
Actions #1

Updated by laforge almost 6 years ago

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

Updated by laforge almost 6 years 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.

Actions #3

Updated by laforge over 5 years 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!

Actions #4

Updated by daniel over 5 years 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

Actions #5

Updated by laforge about 3 years ago

  • Assignee changed from laforge to daniel
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)