Feature #3682
closedIntra-domain connection of OsmoBSC to multiple MSCs
Added by laforge over 5 years ago. Updated over 3 years ago.
100%
Description
3GPP TS 23.236 specifies the "Intra-domain connection of
Radio Access Network (RAN nodes to multiple Core Network (CN) nodes".
- a deviation from the strict hierarchy of classic GSM architecture where a BSC is always only served by one MSC
- the introduction of "MSC pools" where a pool of multiple MSCs cover one geographic service area.
This appears to be functioning by dividing the TMSI range between different MSCs, using the higher-order TMSI bits to identify the MSC and the lower-order TMSI bits for the actual TMSI within that MSC.
Section 5.3 describes the functions required to be implemented in the BSC.- NAS Node Selection Function
- investigate Initial L3 message at RR establishment
- if TMSI is present, extract NRI and route requeest to MSC for that NRI
- if only IMEI or IMSI is present, or no route for that NRI, send to 'ramdom' MSC (load distribution)
- when any MSC sends a PAGING REQUEST, store the IMSI <-> MSC relation as long as the paging is active
- any incoming response to that paging gets routed to the MSC that has issued the paging
Files
| 142217065-MSC-Pool.pdf | View 142217065-MSC-Pool.pdf | 605 KB | description of MSC pool feature | laforge, 09/04/2019 09:01 AM | |
| success_first_msc_pooling.tgz | success_first_msc_pooling.tgz | 509 KB | pcap and config files of first working MSC pooling | neels, 05/26/2020 11:24 PM |
Checklist
- Function for deriving NRI from TMSI
- storing of Global-CN-ID when receiving paging from MSC; routing paging response to that Global-CN-ID
- VTY configuration of number of TMSI bits reserved for NRI
- VTY configuration of NRI <-> MSC SCCP address mappings
- ability to establish A to multiple MSCs simultaneously
- NAS Node Selection Function
- figure out how to test with multiple MSCs in ttcn-bsc-tests
- ensure NULL-NRI config and behavior
- add counters for MSC pooling
- ttcn3 tests
- code review and merge patches
Related issues
Updated by laforge over 4 years ago
- File 142217065-MSC-Pool.pdf 142217065-MSC-Pool.pdf added
- Assignee deleted (
laforge)
Updated by laforge about 4 years ago
- Checklist item changed from splitting of TMSI allocation range/spce to Function for deriving NRI from TMSI
- Checklist item ability to establish A to multiple MSCs simultaneously added
- Checklist item NAS Node Selection Function added
- Description updated (diff)
- Spec Reference set to TS 23.236
Updated by laforge about 4 years ago
- different NRI bit-width
- routing of TMSI with active MSC configured for NRI
- routing of TMSI with disconnected MSC configured for NRI
- routing of TMSI without any MSC configured for NRI
- routing of TMSI with NULL NRI
- routing of PAGING RESPONSE back to correct MSC that requested paging
Updated by laforge about 4 years ago
- Related to Feature #4472: Intra-domain connection of OsmoGBPROXY to multiple SGSNs (pooling) added
Updated by laforge about 4 years ago
- Related to Feature #3454: disable/constrain/hide "multiple msc" concept added
Updated by neels almost 4 years ago
Most parts of 23.236 are quite clear to me, except these:
NAS Node Selection Function
The BSC (RNC) selects an MSC to service new MS (UE). It says this selection is implementation specific.
Should osmo-bsc be able to take into account how loaded each MSC is? If yes, how?
- We could do round-robin between configured MSCs for each not yet assigned MS.
- The BSC could try to keep counters of Location Updatings and IMSI Detach. However, it would also have to track each IMSI with its periodic LU period to not lose implicit detach from periodic LU timeout. That would amount to a second VLR in the BSC, probably not what we want.
- The BSC could somehow communicate with the MSC, e.g. receive load indications from the MSC (am not aware of such messages specified by 3GPP).
- Also, 23.236 names "low access priority" MS (Machine Type Comms), i.e. a way to direct specific kinds of subscribers to a particular MSC. We could easily make provision for marking specific MSCs as low access priority, but the question would be how to identify those MS: by IMSI regular expression? by communication with the HLR via MSC (am not aware of such messages specified by 3GPP)? We could make provision for IMSI regexes to directly select specific MSCs by osmo-bsc.cfg, if that makes any sense.
Non-Broadcast LAI
For Load Re-Distribution, the sequence outlined in the specs is:
- configure the BSC to no longer assign new MS to an MSC that should be unloaded.
- switch the MSC to unloading mode.
- wait several periodic LU periods, so that the MSC responds to periodic LU requests with a NULL NRI, as well as a Non-Broadcast LAI.
- in CS, the "terminal" [sic], because of the Non-Broadcast LAI, immediately re-issues another LU.
- the RAN then sees the NULL NRI in the LU and picks another MSC for the LU.
How does this Non-Broadcast LAI work?
The spec says that each MSC must have an individual LAI assigned to be its own unique Non-Broadcast LAI, i.e. it is a configured item per-MSC.
However, the above sequence suggests that the MS is the one re-issuing another LU request right away (the "terminal"?).
How should the MS know the individually configured Non-Broadcast LAIs?
Is this simply a LAI that mismatches the cell's LAI somehow and thus the MS rejects the LU Accept message?
Re-Distribution: communicate between MSCs
Apparently the above Non-Broadcast LAI should be used to communicate between the two MSCs:
Each CN node in the pool has to be aware of the non-broadcast LAI/RAI assigned to the
other CN nodes in the pool, because in case of re-distribution the 'target CN node' will retrieve data (e.g. IMSI, security
context, MM & PDP contexts) from the 'offloaded CN node' based on non-broadcast LAI/RAI.We have no provision made for OsmoMSCs to communicate in this way.
Will we implement some Osmocom-specific inter-MSC GSUP communication for this (and need to correlate Non-Broadcast LAIs to MSCs' GSUP IPA names in osmo-msc.cfg)?
Will we not do Load Re-Distribution at all?
Should we still have a good plan to add it in the future?
(Also I am thinking, if the MSCs involved in the re-distribution do communicate with each other,
why even send the NULL NRI and not directly the new MSC's NRI?
I'm guessing to leave the decision for which other MSC is chosen in the RAN...)
Updated by neels almost 4 years ago
Another open question:
The spec shows two bits of the TMSI as "CS/PS", and a number of bits (e.g. 5) for 'VLR-restart'.
When we implement assigning TMSIs with NRI in osmo-msc, should we also make provision for these parts of a TMSI?
CS/PS
Since TMSI and pTMSI live in separate domains, I see no benefit in keeping the upper two bits constant per domain.
I'm guessing this is for scenarios where CS and PS are routed more intimately, as some parts of 23.236 hint at.
VLR-restart
It is not apparent from 23.236 how the VLR-restart bits are useful to a CN. So far I am guessing:
It may avoid TMSI collisions where a restarted VLR assigns a TMSI that another MS still assumes to possess.
That MS would try to Layer-3-Complete with its TMSI, would be accepted as another MS, but then the auth should fail, causing re-attach by IMSI.
If this collision is avoided, that means that an Identity Request for IMSI is issued as part of the first LU.
The suggested 5 bits for VLR-Restart seem to suggest that a VLR likely restarts up to 31 times before MS re-attach and get new TMSIs?
or that each time a VLR restarts, the VLR-restart bits are chosen randomly, in the hope to pick a different value every time??
Either way, seems to me a lot of TMSI bits sacrificed for a minor improvement, but what do I know.
Updated by neels almost 4 years ago
- Checklist item Function for deriving NRI from TMSI set to Done
Updated by neels almost 4 years ago
- Checklist item figure out how to test with multiple MSCs in ttcn-bsc-tests added
We need multiple MSCs in the ttcn-bsc-tests
Updated by neels almost 4 years ago
- Status changed from New to In Progress
- Assignee set to neels
Updated by laforge almost 4 years ago
neels wrote:
Should osmo-bsc be able to take into account how loaded each MSC is? If yes, how?
I would go for a simple implementation first, e.g.
- We could do round-robin between configured MSCs for each not yet assigned MS.
exactly.
If somebody needs a more complex scheme, we could always add that as a separate second stage.
Non-Broadcast LAI
For Load Re-Distribution, the sequence outlined in the specs is:
- configure the BSC to no longer assign new MS to an MSC that should be unloaded.
- switch the MSC to unloading mode.
- wait several periodic LU periods, so that the MSC responds to periodic LU requests with a NULL NRI, as well as a Non-Broadcast LAI.
- in CS, the "terminal" [sic], because of the Non-Broadcast LAI, immediately re-issues another LU.
- the RAN then sees the NULL NRI in the LU and picks another MSC for the LU.
How does this Non-Broadcast LAI work?
It is a LAI that is never broadcast, i.e. it is never advertised in SYSTEM INFORMATION, but you return it only in the LU ACCEPT on the dedicated (hence non-broadcast) channel to the MS.
The spec says that each MSC must have an individual LAI assigned to be its own unique Non-Broadcast LAI, i.e. it is a configured item per-MSC.
However, the above sequence suggests that the MS is the one re-issuing another LU request right away (the "terminal"?).
Yes, the MS is doing that if the LU ACCEPT contains a LAI that is != the one of the SI of the cell it camps on.
How should the MS know the individually configured Non-Broadcast LAIs?
Is this simply a LAI that mismatches the cell's LAI somehow and thus the MS rejects the LU Accept message?
Exactly.
We have no provision made for OsmoMSCs to communicate in this way.
Will we implement some Osmocom-specific inter-MSC GSUP communication for this (and need to correlate Non-Broadcast LAIs to MSCs' GSUP IPA names in osmo-msc.cfg)?
Will we not do Load Re-Distribution at all?
Should we still have a good plan to add it in the future?
This feature is about OsmoBSC. OsmoMSC is out of scope.
Updated by laforge almost 4 years ago
neels wrote:
Another open question:
The spec shows two bits of the TMSI as "CS/PS", and a number of bits (e.g. 5) for 'VLR-restart'.
When we implement assigning TMSIs with NRI in osmo-msc, should we also make provision for these parts of a TMSI?
OsmoMSC is out of scope for this feature development. It may only be required for testing (if TTCN-3 based testing is not sufficient and/or one wantes to do real end-to-end testing. So whatever we extend on OsmoMSC, it should be minimized in terms of effort as the BSC is what's in scope, not the MSC.
CS/PS
Since TMSI and pTMSI live in separate domains, I see no benefit in keeping the upper two bits constant per domain.
I'm guessing this is for scenarios where CS and PS are routed more intimately, as some parts of 23.236 hint at.
The question is whether or not this is mandatory as per spec. If it's mandatory, we have to do it. IF not, we can do whatever is easy for us.
VLR-restart
It is not apparent from 23.236 how the VLR-restart bits are useful to a CN. So far I am guessing:
I also don't know without re-reading. But why is this relevant for developing the related code in OsmoBSC? The BSC cannot influence
which TMSIs are allocated in the MSC anyway.
Updated by neels almost 4 years ago
In BSC_Tests.ttcn, I have managed to duplicate the BSSAP connections.
However, I now realize that we will have the same issue that I've faced in the MSC_Tests.ttcn for inter-BSC handover testing:
Each testing function will run on a separate MSC_ConnHdlr, and thus I will need concurrent testing functions, one for each MSC.
For example, in MSC_Tests.ttcn, TC_ho_inter_bsc(), I coordinate an inter-BSC handover by running f_tc_ho_inter_bsc0() and f_tc_ho_inter_bsc1() concurrently,
and waiting for certain events to occur (or have a sufficient delay) to orchestrate between the two functions.
That can work fine, only I just realized that the tests will not be strictly sequential and might be a bit hard for the reader to follow.
- Three RSL L3-Complete requests for different NRI from a BTS, three separate test functions each expect one L3-Complete for their NRI.
- Paging: three test functions, each on a different MSC, each sending out a Paging for a different identity and expecting their own Paging Responses.
- NULL NRI: one test function responds upon LU with a NULL NRI, a second test function merely waits for a LU and accepts it.
- ...
IIUC each concurrent test function will be able to interact with the RSL side, so the RSL part should probably be written in only one of the test functions for clarity?
I wonder if that will work out well.
Updated by neels almost 4 years ago
the patch is http://git.osmocom.org/osmo-ttcn3-hacks/commit/?h=neels/mscpool&id=080aa41f2c179bed65664cfa8228f2bea7708764
"bsc: allow multiple MSCs"
BSC tests still pass with this after adjusting the BSC_Tests.cfg in docker-playground http://git.osmocom.org/docker-playground/commit/?h=neels/mscpool&id=038c048d27c3c4b5eb6a2e433cca447a2b030529
"bsc: adjust cfg for multiple MSCs, msc: tweak comments in cfg"
Updated by laforge almost 4 years ago
On Wed, May 13, 2020 at 12:55:23AM +0000, neels [REDMINE] wrote:
In BSC_Tests.ttcn, I have managed to duplicate the BSSAP connections.
great!
However, I now realize that we will have the same issue that I've faced in the MSC_Tests.ttcn for inter-BSC handover testing:
Each testing function will run on a separate MSC_ConnHdlr, and thus I will need concurrent testing functions, one for each MSC.
I thought contrary to hand-over, this is what you wanted for the MSC-pool work?
- Three RSL L3-Complete requests for different NRI from a BTS, three separate test functions each expect one L3-Complete for their NRI.
Shouldn't this simply be three components, each running the same code (with different parameters such as
TMSI)?
What is the need for coordination between them?
side note: Do you even need to run them concurrently? You could also run them sequentially?
- Paging: three test functions, each on a different MSC, each sending out a Paging for a different identity and expecting their own Paging Responses.
Again, same function/testcase on the same component type (ConnHdlr), each just executed with different
parameters leading to using a different BSSAP emulation?
- NULL NRI: one test function responds upon LU with a NULL NRI, a second test function merely waits for a LU and accepts it.
Why is this not handled in one component?
Each component emulates both the MS/BTS side and one MSC. All logic always happens within that component.
IIUC each concurrent test function will be able to interact with the RSL side, so the RSL part should probably be written in only one of the test functions for clarity?
I cannot follow you here, sorry.
Updated by neels almost 4 years ago
laforge wrote:
- Three RSL L3-Complete requests for different NRI from a BTS, three separate test functions each expect one L3-Complete for their NRI.
Shouldn't this simply be three components, each running the same code (with different parameters such as
TMSI)?
yes, that could work. actually it will probably even "disappear" into something like f_location_updating()...
- NULL NRI: one test function responds upon LU with a NULL NRI, a second test function merely waits for a LU and accepts it.
Why is this not handled in one component?
One MSC sends a NULL NRI and non-broadcast LAI, then the subscriber needs come back with that NULL NRI and be redirected to another MSC.
Could of course be modeled in separate parts, too, but would be nice to have all in one scenario...
I guess I'll manage either way.
Updated by neels almost 4 years ago
- File success_first_msc_pooling.tgz success_first_msc_pooling.tgz added
- % Done changed from 10 to 70
I've managed to get MSC pooling by NRI working in a manual test setup!
What remains to do now:
- recap this in ttcn3 test suites.
- implement NULL-NRI behavior.
- code review and merge.
Find attached a pcap. It is most interesting to look at it using the filter wireshark filter
bssap || gsmtap_log.string contains NRI || gsmtap_log.string contains robinBelow is a text rendering of that:
At first, the two MS are new and get round-robined across the two MSC.
As soon as they come back with a TMSI, they get redirected according to the NRI contained in that TMSI,
and each of them "sticks" to its own MSC like that.
Note that, in the end, I model a very unrealistic scenario: I use our IMSI pseudonomization SIM app to change one SIM card's IMSI from 1234567 to 123456 (a version of the app that does not clear the TMSI yet).
After that, the MS still comes back with its previous TMSI and gets routed back to the same MSC as before. Since it is the same SIM, it attaches fine.
In a realistic scenario, a TMSI collision with mismatching IMSIs should abort at the authentication stage instead.
But I do notice that phones tend to pass their previous TMSI even to completely unknown PLMNs.
So we may need some mechanism to throw out unknown TMSIs (using a NULL-NRI) to ensure a round-robin is actually happening,
but OTOH the intrinsic random effect from getting other networks' TMSIs with "random" NRIs may also be sufficient.
No. Time Arrival Time Source Source Port Destination Destination Port Info
581 8.251075 May 27, 2020 01:08:07.136226000 CEST 187 2 UDT (BSSMAP) Reset
582 8.251130 May 27, 2020 01:08:07.136281000 CEST 187 1 UDT (BSSMAP) Reset
584 8.251249 May 27, 2020 01:08:07.136400000 CEST 187 2 UDT (BSSMAP) Reset
585 8.251332 May 27, 2020 01:08:07.136483000 CEST 187 1 UDT (BSSMAP) Reset
598 8.252332 May 27, 2020 01:08:07.137483000 CEST 2 187 SACK UDT (BSSMAP) Reset Acknowledge
599 8.252332 May 27, 2020 01:08:07.137483000 CEST 1 187 SACK UDT (BSSMAP) Reset Acknowledge
600 8.252512 May 27, 2020 01:08:07.137663000 CEST 1 187 UDT (BSSMAP) Reset Acknowledge
601 8.252551 May 27, 2020 01:08:07.137702000 CEST 2 187 UDT (BSSMAP) Reset Acknowledge
1065 56.472573 May 27, 2020 01:08:55.357724000 CEST 127.0.0.1 57511 127.0.0.1 4729 New subscriber IMSI-901700000014706: MSC round-robin selects msc 0
1074 56.473165 May 27, 2020 01:08:55.358316000 CEST 187 1 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) Location Updating Request
1075 56.473290 May 27, 2020 01:08:55.358441000 CEST 187 1 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) Location Updating Request
1210 56.495545 May 27, 2020 01:08:55.380696000 CEST 1 187 DT1 (DTAP) (MM) Authentication Request
1212 56.495930 May 27, 2020 01:08:55.381081000 CEST 1 187 DT1 (DTAP) (MM) Authentication Request
1234 57.413987 May 27, 2020 01:08:56.299138000 CEST 187 1 DT1 (DTAP) (MM) Authentication Response
1235 57.414157 May 27, 2020 01:08:56.299308000 CEST 187 1 DT1 (DTAP) (MM) Authentication Response
1263 57.415709 May 27, 2020 01:08:56.300860000 CEST 1 187 SACK DT1 (BSSMAP) Classmark Request
1264 57.415789 May 27, 2020 01:08:56.300940000 CEST 1 187 SACK DT1 (BSSMAP) Classmark Request
1286 57.885445 May 27, 2020 01:08:56.770596000 CEST 187 1 DT1 (BSSMAP) Classmark Update
1287 57.885895 May 27, 2020 01:08:56.771046000 CEST 187 1 DT1 (BSSMAP) Classmark Update
1305 57.888028 May 27, 2020 01:08:56.773179000 CEST 1 187 SACK DT1 (BSSMAP) Cipher Mode Command
1306 57.888117 May 27, 2020 01:08:56.773268000 CEST 1 187 SACK DT1 (BSSMAP) Cipher Mode Command
1325 58.356490 May 27, 2020 01:08:57.241641000 CEST 187 1 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
1326 58.356732 May 27, 2020 01:08:57.241883000 CEST 187 1 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
1404 58.373186 May 27, 2020 01:08:57.258337000 CEST 1 187 SACK DT1 (DTAP) (MM) Identity Request
1405 58.373355 May 27, 2020 01:08:57.258506000 CEST 1 187 SACK DT1 (DTAP) (MM) Identity Request
1423 58.827246 May 27, 2020 01:08:57.712397000 CEST 187 1 DT1 (DTAP) (MM) Identity Response
1424 58.827656 May 27, 2020 01:08:57.712807000 CEST 187 1 DT1 (DTAP) (MM) Identity Response
1452 58.835860 May 27, 2020 01:08:57.721011000 CEST 127.0.0.1 56618 127.0.0.1 4729 New NRI from range [0x0..0x1ff] = 0xed --> TMSI 0x033b70fc
1461 58.837998 May 27, 2020 01:08:57.723149000 CEST 1 187 SACK DT1 (DTAP) (MM) Location Updating Accept
1462 58.838535 May 27, 2020 01:08:57.723686000 CEST 1 187 SACK DT1 (DTAP) (MM) Location Updating Accept
1481 59.296694 May 27, 2020 01:08:58.181845000 CEST 187 1 DT1 (DTAP) (MM) TMSI Reallocation Complete
1482 59.296871 May 27, 2020 01:08:58.182022000 CEST 187 1 DT1 (DTAP) (MM) TMSI Reallocation Complete
1517 59.304231 May 27, 2020 01:08:58.189382000 CEST 1 187 SACK DT1 (BSSMAP) Clear Command
1518 59.304459 May 27, 2020 01:08:58.189610000 CEST 1 187 SACK DT1 (BSSMAP) Clear Command
1534 59.305849 May 27, 2020 01:08:58.191000000 CEST 187 1 SACK DT1 (BSSMAP) Clear Complete
1536 59.305949 May 27, 2020 01:08:58.191100000 CEST 187 1 SACK DT1 (BSSMAP) Clear Complete
2041 78.127254 May 27, 2020 01:09:17.012405000 CEST 127.0.0.1 57511 127.0.0.1 4729 New subscriber IMSI-1234567: MSC round-robin selects msc 1
2050 78.127754 May 27, 2020 01:09:17.012905000 CEST 187 2 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) Location Updating Request
2051 78.127849 May 27, 2020 01:09:17.013000000 CEST 187 2 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) Location Updating Request
2186 78.144018 May 27, 2020 01:09:17.029169000 CEST 2 187 DT1 (DTAP) (MM) Authentication Request
2188 78.144108 May 27, 2020 01:09:17.029259000 CEST 2 187 DT1 (DTAP) (MM) Authentication Request
2209 79.069480 May 27, 2020 01:09:17.954631000 CEST 187 2 DT1 (DTAP) (MM) Authentication Response
2210 79.069685 May 27, 2020 01:09:17.954836000 CEST 187 2 DT1 (DTAP) (MM) Authentication Response
2238 79.071724 May 27, 2020 01:09:17.956875000 CEST 2 187 SACK DT1 (BSSMAP) Classmark Request
2239 79.071901 May 27, 2020 01:09:17.957052000 CEST 2 187 SACK DT1 (BSSMAP) Classmark Request
2260 79.540547 May 27, 2020 01:09:18.425698000 CEST 187 2 DT1 (BSSMAP) Classmark Update
2261 79.540709 May 27, 2020 01:09:18.425860000 CEST 187 2 DT1 (BSSMAP) Classmark Update
2279 79.543289 May 27, 2020 01:09:18.428440000 CEST 2 187 SACK DT1 (BSSMAP) Cipher Mode Command
2280 79.543617 May 27, 2020 01:09:18.428768000 CEST 2 187 SACK DT1 (BSSMAP) Cipher Mode Command
2300 80.011861 May 27, 2020 01:09:18.897012000 CEST 187 2 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
2301 80.012130 May 27, 2020 01:09:18.897281000 CEST 187 2 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
2377 80.034489 May 27, 2020 01:09:18.919640000 CEST 2 187 SACK DT1 (DTAP) (MM) Identity Request
2378 80.034639 May 27, 2020 01:09:18.919790000 CEST 2 187 SACK DT1 (DTAP) (MM) Identity Request
2398 80.481829 May 27, 2020 01:09:19.366980000 CEST 187 2 DT1 (DTAP) (MM) Identity Response
2399 80.482022 May 27, 2020 01:09:19.367173000 CEST 187 2 DT1 (DTAP) (MM) Identity Response
2427 80.485190 May 27, 2020 01:09:19.370341000 CEST 127.0.0.1 57597 127.0.0.1 4729 New NRI from range [0x200..0x3ff] = 0x307 --> TMSI 0x8ac1e24b
2436 80.486215 May 27, 2020 01:09:19.371366000 CEST 2 187 SACK DT1 (DTAP) (MM) Location Updating Accept
2437 80.486479 May 27, 2020 01:09:19.371630000 CEST 2 187 SACK DT1 (DTAP) (MM) Location Updating Accept
2456 80.953097 May 27, 2020 01:09:19.838248000 CEST 187 2 DT1 (DTAP) (MM) TMSI Reallocation Complete
2457 80.953496 May 27, 2020 01:09:19.838647000 CEST 187 2 DT1 (DTAP) (MM) TMSI Reallocation Complete
2492 80.968929 May 27, 2020 01:09:19.854080000 CEST 2 187 SACK DT1 (BSSMAP) Clear Command
2493 80.969212 May 27, 2020 01:09:19.854363000 CEST 2 187 SACK DT1 (BSSMAP) Clear Command
2509 80.972468 May 27, 2020 01:09:19.857619000 CEST 187 2 SACK DT1 (BSSMAP) Clear Complete
2511 80.972792 May 27, 2020 01:09:19.857943000 CEST 187 2 SACK DT1 (BSSMAP) Clear Complete
2722 99.783362 May 27, 2020 01:09:38.668513000 CEST 127.0.0.1 57511 127.0.0.1 4729 TMSI 0x033b70fc yields NRI = 0xed
2723 99.783431 May 27, 2020 01:09:38.668582000 CEST 127.0.0.1 57511 127.0.0.1 4729 NRI 0xed from TMSI 0x033b70fc matches msc 0
2732 99.784125 May 27, 2020 01:09:38.669276000 CEST 187 1 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) CM Service Request
2733 99.784327 May 27, 2020 01:09:38.669478000 CEST 187 1 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) CM Service Request
2774 99.787788 May 27, 2020 01:09:38.672939000 CEST 1 187 DT1 (DTAP) (MM) Authentication Request
2777 99.787943 May 27, 2020 01:09:38.673094000 CEST 1 187 DT1 (DTAP) (MM) Authentication Request
2829 100.724302 May 27, 2020 01:09:39.609453000 CEST 187 1 DT1 (DTAP) (MM) Authentication Response
2830 100.724480 May 27, 2020 01:09:39.609631000 CEST 187 1 DT1 (DTAP) (MM) Authentication Response
2858 100.725958 May 27, 2020 01:09:39.611109000 CEST 1 187 SACK DT1 (BSSMAP) Cipher Mode Command
2859 100.726040 May 27, 2020 01:09:39.611191000 CEST 1 187 SACK DT1 (BSSMAP) Cipher Mode Command
2879 101.196002 May 27, 2020 01:09:40.081153000 CEST 187 1 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
2880 101.196129 May 27, 2020 01:09:40.081280000 CEST 187 1 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
2931 101.666941 May 27, 2020 01:09:40.552092000 CEST 187 1 DT1 (DTAP) (SS) Register (GSM MAP) invoke processUnstructuredSS-Request
2932 101.667213 May 27, 2020 01:09:40.552364000 CEST 187 1 DT1 (DTAP) (SS) Register (GSM MAP) invoke processUnstructuredSS-Request
2983 101.672891 May 27, 2020 01:09:40.558042000 CEST 1 187 SACK DT1 (DTAP) (SS) Release Complete (GSM MAP) returnResultLast processUnstructuredSS-Request
2984 101.672952 May 27, 2020 01:09:40.558103000 CEST 1 187 DT1 (BSSMAP) Clear Command
2986 101.673089 May 27, 2020 01:09:40.558240000 CEST 1 187 SACK DT1 (DTAP) (SS) Release Complete (GSM MAP) returnResultLast processUnstructuredSS-Request
2987 101.673136 May 27, 2020 01:09:40.558287000 CEST 1 187 DT1 (BSSMAP) Clear Command
3010 101.674797 May 27, 2020 01:09:40.559948000 CEST 187 1 DT1 (BSSMAP) Clear Complete
3011 101.674874 May 27, 2020 01:09:40.560025000 CEST 187 1 DT1 (BSSMAP) Clear Complete
3282 114.141944 May 27, 2020 01:09:53.027095000 CEST 127.0.0.1 57511 127.0.0.1 4729 TMSI 0x033b70fc yields NRI = 0xed
3283 114.142013 May 27, 2020 01:09:53.027164000 CEST 127.0.0.1 57511 127.0.0.1 4729 NRI 0xed from TMSI 0x033b70fc matches msc 0
3292 114.142889 May 27, 2020 01:09:53.028040000 CEST 187 1 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) CM Service Request
3293 114.143037 May 27, 2020 01:09:53.028188000 CEST 187 1 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) CM Service Request
3334 114.146555 May 27, 2020 01:09:53.031706000 CEST 1 187 DT1 (DTAP) (MM) Authentication Request
3337 114.146750 May 27, 2020 01:09:53.031901000 CEST 1 187 DT1 (DTAP) (MM) Authentication Request
3363 115.083753 May 27, 2020 01:09:53.968904000 CEST 187 1 DT1 (DTAP) (MM) Authentication Response
3364 115.083987 May 27, 2020 01:09:53.969138000 CEST 187 1 DT1 (DTAP) (MM) Authentication Response
3392 115.087400 May 27, 2020 01:09:53.972551000 CEST 1 187 SACK DT1 (BSSMAP) Cipher Mode Command
3393 115.087644 May 27, 2020 01:09:53.972795000 CEST 1 187 SACK DT1 (BSSMAP) Cipher Mode Command
3412 115.554902 May 27, 2020 01:09:54.440053000 CEST 187 1 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
3413 115.555149 May 27, 2020 01:09:54.440300000 CEST 187 1 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
3451 116.024622 May 27, 2020 01:09:54.909773000 CEST 187 1 DT1 (DTAP) (SS) Register (GSM MAP) invoke processUnstructuredSS-Request
3452 116.024787 May 27, 2020 01:09:54.909938000 CEST 187 1 DT1 (DTAP) (SS) Register (GSM MAP) invoke processUnstructuredSS-Request
3503 116.030034 May 27, 2020 01:09:54.915185000 CEST 1 187 SACK DT1 (DTAP) (SS) Release Complete (GSM MAP) returnResultLast processUnstructuredSS-Request
3504 116.030121 May 27, 2020 01:09:54.915272000 CEST 1 187 DT1 (BSSMAP) Clear Command
3506 116.030307 May 27, 2020 01:09:54.915458000 CEST 1 187 SACK DT1 (DTAP) (SS) Release Complete (GSM MAP) returnResultLast processUnstructuredSS-Request
3507 116.030360 May 27, 2020 01:09:54.915511000 CEST 1 187 DT1 (BSSMAP) Clear Command
3530 116.032514 May 27, 2020 01:09:54.917665000 CEST 187 1 DT1 (BSSMAP) Clear Complete
3531 116.032678 May 27, 2020 01:09:54.917829000 CEST 187 1 DT1 (BSSMAP) Clear Complete
3698 122.146186 May 27, 2020 01:10:01.031337000 CEST 127.0.0.1 57511 127.0.0.1 4729 TMSI 0x8ac1e24b yields NRI = 0x307
3699 122.146422 May 27, 2020 01:10:01.031573000 CEST 127.0.0.1 57511 127.0.0.1 4729 NRI 0x307 from TMSI 0x8ac1e24b matches msc 1
3708 122.148784 May 27, 2020 01:10:01.033935000 CEST 187 2 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) CM Service Request
3709 122.149192 May 27, 2020 01:10:01.034343000 CEST 187 2 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) CM Service Request
3751 122.158035 May 27, 2020 01:10:01.043186000 CEST 2 187 DT1 (DTAP) (MM) Authentication Request
3753 122.158308 May 27, 2020 01:10:01.043459000 CEST 2 187 DT1 (DTAP) (MM) Authentication Request
3774 123.086972 May 27, 2020 01:10:01.972123000 CEST 187 2 DT1 (DTAP) (MM) Authentication Response
3775 123.087208 May 27, 2020 01:10:01.972359000 CEST 187 2 DT1 (DTAP) (MM) Authentication Response
3803 123.090992 May 27, 2020 01:10:01.976143000 CEST 2 187 SACK DT1 (BSSMAP) Cipher Mode Command
3804 123.091335 May 27, 2020 01:10:01.976486000 CEST 2 187 SACK DT1 (BSSMAP) Cipher Mode Command
3823 123.558634 May 27, 2020 01:10:02.443785000 CEST 187 2 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
3824 123.558875 May 27, 2020 01:10:02.444026000 CEST 187 2 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
3865 124.027489 May 27, 2020 01:10:02.912640000 CEST 187 2 DT1 (DTAP) (SS) Register (GSM MAP) invoke processUnstructuredSS-Request
3866 124.027648 May 27, 2020 01:10:02.912799000 CEST 187 2 DT1 (DTAP) (SS) Register (GSM MAP) invoke processUnstructuredSS-Request
3917 124.031226 May 27, 2020 01:10:02.916377000 CEST 2 187 SACK DT1 (DTAP) (SS) Release Complete (GSM MAP) returnResultLast processUnstructuredSS-Request
3918 124.031267 May 27, 2020 01:10:02.916418000 CEST 2 187 DT1 (BSSMAP) Clear Command
3920 124.031385 May 27, 2020 01:10:02.916536000 CEST 2 187 SACK DT1 (DTAP) (SS) Release Complete (GSM MAP) returnResultLast processUnstructuredSS-Request
3921 124.031425 May 27, 2020 01:10:02.916576000 CEST 2 187 DT1 (BSSMAP) Clear Command
3944 124.032749 May 27, 2020 01:10:02.917900000 CEST 187 2 DT1 (BSSMAP) Clear Complete
3945 124.032815 May 27, 2020 01:10:02.917966000 CEST 187 2 DT1 (BSSMAP) Clear Complete
4082 130.854145 May 27, 2020 01:10:09.739296000 CEST 127.0.0.1 57511 127.0.0.1 4729 TMSI 0x8ac1e24b yields NRI = 0x307
4083 130.854215 May 27, 2020 01:10:09.739366000 CEST 127.0.0.1 57511 127.0.0.1 4729 NRI 0x307 from TMSI 0x8ac1e24b matches msc 1
4092 130.855024 May 27, 2020 01:10:09.740175000 CEST 187 2 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) CM Service Request
4093 130.855170 May 27, 2020 01:10:09.740321000 CEST 187 2 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) CM Service Request
4134 130.858316 May 27, 2020 01:10:09.743467000 CEST 2 187 DT1 (DTAP) (MM) Authentication Request
4137 130.858507 May 27, 2020 01:10:09.743658000 CEST 2 187 DT1 (DTAP) (MM) Authentication Request
4161 131.795198 May 27, 2020 01:10:10.680349000 CEST 187 2 DT1 (DTAP) (MM) Authentication Response
4162 131.795323 May 27, 2020 01:10:10.680474000 CEST 187 2 DT1 (DTAP) (MM) Authentication Response
4190 131.796830 May 27, 2020 01:10:10.681981000 CEST 2 187 SACK DT1 (BSSMAP) Cipher Mode Command
4191 131.796929 May 27, 2020 01:10:10.682080000 CEST 2 187 SACK DT1 (BSSMAP) Cipher Mode Command
4211 132.266277 May 27, 2020 01:10:11.151428000 CEST 187 2 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
4212 132.266415 May 27, 2020 01:10:11.151566000 CEST 187 2 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
4249 132.737247 May 27, 2020 01:10:11.622398000 CEST 187 2 DT1 (DTAP) (SS) Register (GSM MAP) invoke processUnstructuredSS-Request
4250 132.737423 May 27, 2020 01:10:11.622574000 CEST 187 2 DT1 (DTAP) (SS) Register (GSM MAP) invoke processUnstructuredSS-Request
4301 132.742897 May 27, 2020 01:10:11.628048000 CEST 2 187 SACK DT1 (DTAP) (SS) Release Complete (GSM MAP) returnResultLast processUnstructuredSS-Request
4302 132.743003 May 27, 2020 01:10:11.628154000 CEST 2 187 DT1 (BSSMAP) Clear Command
4304 132.743135 May 27, 2020 01:10:11.628286000 CEST 2 187 SACK DT1 (DTAP) (SS) Release Complete (GSM MAP) returnResultLast processUnstructuredSS-Request
4305 132.743176 May 27, 2020 01:10:11.628327000 CEST 2 187 DT1 (BSSMAP) Clear Command
4328 132.748246 May 27, 2020 01:10:11.633397000 CEST 187 2 DT1 (BSSMAP) Clear Complete
4329 132.748367 May 27, 2020 01:10:11.633518000 CEST 187 2 DT1 (BSSMAP) Clear Complete
4540 137.923895 May 27, 2020 01:10:16.809046000 CEST 127.0.0.1 57511 127.0.0.1 4729 TMSI 0x033b70fc yields NRI = 0xed
4541 137.923981 May 27, 2020 01:10:16.809132000 CEST 127.0.0.1 57511 127.0.0.1 4729 NRI 0xed from TMSI 0x033b70fc matches msc 0
4547 137.924772 May 27, 2020 01:10:16.809923000 CEST 187 1 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) IMSI Detach Indication
4548 137.924965 May 27, 2020 01:10:16.810116000 CEST 187 1 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) IMSI Detach Indication
4586 137.929209 May 27, 2020 01:10:16.814360000 CEST 1 187 DT1 (BSSMAP) Clear Command
4589 137.929615 May 27, 2020 01:10:16.814766000 CEST 1 187 DT1 (BSSMAP) Clear Command
4609 137.932270 May 27, 2020 01:10:16.817421000 CEST 187 1 DT1 (BSSMAP) Clear Complete
4610 137.932474 May 27, 2020 01:10:16.817625000 CEST 187 1 DT1 (BSSMAP) Clear Complete
4818 147.802688 May 27, 2020 01:10:26.687839000 CEST 127.0.0.1 57511 127.0.0.1 4729 TMSI 0x8ac1e24b yields NRI = 0x307
4819 147.802835 May 27, 2020 01:10:26.687986000 CEST 127.0.0.1 57511 127.0.0.1 4729 NRI 0x307 from TMSI 0x8ac1e24b matches msc 1
4825 147.805731 May 27, 2020 01:10:26.690882000 CEST 187 2 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) IMSI Detach Indication
4826 147.805985 May 27, 2020 01:10:26.691136000 CEST 187 2 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) IMSI Detach Indication
4864 147.809858 May 27, 2020 01:10:26.695009000 CEST 2 187 DT1 (BSSMAP) Clear Command
4867 147.810029 May 27, 2020 01:10:26.695180000 CEST 2 187 DT1 (BSSMAP) Clear Command
4887 147.811468 May 27, 2020 01:10:26.696619000 CEST 187 2 DT1 (BSSMAP) Clear Complete
4889 147.811606 May 27, 2020 01:10:26.696757000 CEST 187 2 DT1 (BSSMAP) Clear Complete
5021 157.217646 May 27, 2020 01:10:36.102797000 CEST 127.0.0.1 57511 127.0.0.1 4729 TMSI 0x033b70fc yields NRI = 0xed
5022 157.217766 May 27, 2020 01:10:36.102917000 CEST 127.0.0.1 57511 127.0.0.1 4729 NRI 0xed from TMSI 0x033b70fc matches msc 0
5031 157.219171 May 27, 2020 01:10:36.104322000 CEST 187 1 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) Location Updating Request
5032 157.219440 May 27, 2020 01:10:36.104591000 CEST 187 1 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) Location Updating Request
5074 157.225146 May 27, 2020 01:10:36.110297000 CEST 1 187 DT1 (DTAP) (MM) Identity Request
5077 157.225396 May 27, 2020 01:10:36.110547000 CEST 1 187 DT1 (DTAP) (MM) Identity Request
5099 157.687963 May 27, 2020 01:10:36.573114000 CEST 187 1 DT1 (DTAP) (MM) Identity Response
5100 157.688277 May 27, 2020 01:10:36.573428000 CEST 187 1 DT1 (DTAP) (MM) Identity Response
5206 157.707270 May 27, 2020 01:10:36.592421000 CEST 1 187 SACK DT1 (DTAP) (MM) Authentication Request
5207 157.707540 May 27, 2020 01:10:36.592691000 CEST 1 187 SACK DT1 (DTAP) (MM) Authentication Request
5229 158.628987 May 27, 2020 01:10:37.514138000 CEST 187 1 DT1 (DTAP) (MM) Authentication Response
5230 158.629162 May 27, 2020 01:10:37.514313000 CEST 187 1 DT1 (DTAP) (MM) Authentication Response
5258 158.630694 May 27, 2020 01:10:37.515845000 CEST 1 187 SACK DT1 (BSSMAP) Classmark Request
5259 158.630788 May 27, 2020 01:10:37.515939000 CEST 1 187 SACK DT1 (BSSMAP) Classmark Request
5281 159.100210 May 27, 2020 01:10:37.985361000 CEST 187 1 DT1 (BSSMAP) Classmark Update
5282 159.100340 May 27, 2020 01:10:37.985491000 CEST 187 1 DT1 (BSSMAP) Classmark Update
5300 159.101240 May 27, 2020 01:10:37.986391000 CEST 1 187 SACK DT1 (BSSMAP) Cipher Mode Command
5301 159.101314 May 27, 2020 01:10:37.986465000 CEST 1 187 SACK DT1 (BSSMAP) Cipher Mode Command
5320 159.571244 May 27, 2020 01:10:38.456395000 CEST 187 1 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
5321 159.571530 May 27, 2020 01:10:38.456681000 CEST 187 1 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
5399 159.586238 May 27, 2020 01:10:38.471389000 CEST 1 187 SACK DT1 (DTAP) (MM) Identity Request
5400 159.586484 May 27, 2020 01:10:38.471635000 CEST 1 187 SACK DT1 (DTAP) (MM) Identity Request
5419 160.042164 May 27, 2020 01:10:38.927315000 CEST 187 1 DT1 (DTAP) (MM) Identity Response
5420 160.042379 May 27, 2020 01:10:38.927530000 CEST 187 1 DT1 (DTAP) (MM) Identity Response
5448 160.046397 May 27, 2020 01:10:38.931548000 CEST 127.0.0.1 56618 127.0.0.1 4729 New NRI from range [0x0..0x1ff] = 0x177 --> TMSI 0xa55ded22
5457 160.047456 May 27, 2020 01:10:38.932607000 CEST 1 187 SACK DT1 (DTAP) (MM) Location Updating Accept
5458 160.047604 May 27, 2020 01:10:38.932755000 CEST 1 187 SACK DT1 (DTAP) (MM) Location Updating Accept
5476 160.512838 May 27, 2020 01:10:39.397989000 CEST 187 1 DT1 (DTAP) (MM) TMSI Reallocation Complete
5477 160.512959 May 27, 2020 01:10:39.398110000 CEST 187 1 DT1 (DTAP) (MM) TMSI Reallocation Complete
5517 160.518627 May 27, 2020 01:10:39.403778000 CEST 1 187 SACK DT1 (DTAP) (MM) MM Information
5518 160.518667 May 27, 2020 01:10:39.403818000 CEST 1 187 DT1 (BSSMAP) Clear Command
5520 160.518779 May 27, 2020 01:10:39.403930000 CEST 1 187 SACK DT1 (DTAP) (MM) MM Information
5521 160.518820 May 27, 2020 01:10:39.403971000 CEST 1 187 DT1 (BSSMAP) Clear Command
5544 160.520402 May 27, 2020 01:10:39.405553000 CEST 187 1 DT1 (BSSMAP) Clear Complete
5545 160.520621 May 27, 2020 01:10:39.405772000 CEST 187 1 DT1 (BSSMAP) Clear Complete
6002 169.456839 May 27, 2020 01:10:48.341990000 CEST 127.0.0.1 57511 127.0.0.1 4729 TMSI 0x8ac1e24b yields NRI = 0x307
6003 169.456888 May 27, 2020 01:10:48.342039000 CEST 127.0.0.1 57511 127.0.0.1 4729 NRI 0x307 from TMSI 0x8ac1e24b matches msc 1
6012 169.457522 May 27, 2020 01:10:48.342673000 CEST 187 2 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) Location Updating Request
6013 169.457646 May 27, 2020 01:10:48.342797000 CEST 187 2 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) Location Updating Request
6055 169.460228 May 27, 2020 01:10:48.345379000 CEST 2 187 DT1 (DTAP) (MM) Identity Request
6058 169.460358 May 27, 2020 01:10:48.345509000 CEST 2 187 DT1 (DTAP) (MM) Identity Request
6099 169.929341 May 27, 2020 01:10:48.814492000 CEST 187 2 DT1 (DTAP) (MM) Identity Response
6100 169.929638 May 27, 2020 01:10:48.814789000 CEST 187 2 DT1 (DTAP) (MM) Identity Response
6206 169.959067 May 27, 2020 01:10:48.844218000 CEST 2 187 SACK DT1 (DTAP) (MM) Authentication Request
6207 169.959190 May 27, 2020 01:10:48.844341000 CEST 2 187 SACK DT1 (DTAP) (MM) Authentication Request
6228 170.869647 May 27, 2020 01:10:49.754798000 CEST 187 2 DT1 (DTAP) (MM) Authentication Response
6229 170.869790 May 27, 2020 01:10:49.754941000 CEST 187 2 DT1 (DTAP) (MM) Authentication Response
6257 170.871788 May 27, 2020 01:10:49.756939000 CEST 2 187 SACK DT1 (BSSMAP) Classmark Request
6258 170.872044 May 27, 2020 01:10:49.757195000 CEST 2 187 SACK DT1 (BSSMAP) Classmark Request
6280 171.341114 May 27, 2020 01:10:50.226265000 CEST 187 2 DT1 (BSSMAP) Classmark Update
6281 171.341361 May 27, 2020 01:10:50.226512000 CEST 187 2 DT1 (BSSMAP) Classmark Update
6299 171.342458 May 27, 2020 01:10:50.227609000 CEST 2 187 SACK DT1 (BSSMAP) Cipher Mode Command
6300 171.342602 May 27, 2020 01:10:50.227753000 CEST 2 187 SACK DT1 (BSSMAP) Cipher Mode Command
6321 171.811761 May 27, 2020 01:10:50.696912000 CEST 187 2 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
6322 171.811932 May 27, 2020 01:10:50.697083000 CEST 187 2 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
6400 171.835147 May 27, 2020 01:10:50.720298000 CEST 2 187 SACK DT1 (DTAP) (MM) Identity Request
6401 171.835403 May 27, 2020 01:10:50.720554000 CEST 2 187 SACK DT1 (DTAP) (MM) Identity Request
6420 172.281594 May 27, 2020 01:10:51.166745000 CEST 187 2 DT1 (DTAP) (MM) Identity Response
6421 172.281752 May 27, 2020 01:10:51.166903000 CEST 187 2 DT1 (DTAP) (MM) Identity Response
6449 172.283191 May 27, 2020 01:10:51.168342000 CEST 127.0.0.1 57597 127.0.0.1 4729 New NRI from range [0x200..0x3ff] = 0x372 --> TMSI 0x08dcbc72
6458 172.283590 May 27, 2020 01:10:51.168741000 CEST 2 187 SACK DT1 (DTAP) (MM) Location Updating Accept
6459 172.283681 May 27, 2020 01:10:51.168832000 CEST 2 187 SACK DT1 (DTAP) (MM) Location Updating Accept
6477 172.752959 May 27, 2020 01:10:51.638110000 CEST 187 2 DT1 (DTAP) (MM) TMSI Reallocation Complete
6478 172.753131 May 27, 2020 01:10:51.638282000 CEST 187 2 DT1 (DTAP) (MM) TMSI Reallocation Complete
6518 172.761805 May 27, 2020 01:10:51.646956000 CEST 2 187 SACK DT1 (DTAP) (MM) MM Information
6519 172.761840 May 27, 2020 01:10:51.646991000 CEST 2 187 DT1 (BSSMAP) Clear Command
6521 172.761952 May 27, 2020 01:10:51.647103000 CEST 2 187 SACK DT1 (DTAP) (MM) MM Information
6522 172.761979 May 27, 2020 01:10:51.647130000 CEST 2 187 DT1 (BSSMAP) Clear Command
6545 172.763075 May 27, 2020 01:10:51.648226000 CEST 187 2 DT1 (BSSMAP) Clear Complete
6546 172.763153 May 27, 2020 01:10:51.648304000 CEST 187 2 DT1 (BSSMAP) Clear Complete
7197 240.543990 May 27, 2020 01:11:59.429141000 CEST 127.0.0.1 57511 127.0.0.1 4729 TMSI 0x08dcbc72 yields NRI = 0x372
7198 240.544067 May 27, 2020 01:11:59.429218000 CEST 127.0.0.1 57511 127.0.0.1 4729 NRI 0x372 from TMSI 0x08dcbc72 matches msc 1
7204 240.544671 May 27, 2020 01:11:59.429822000 CEST 187 2 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) IMSI Detach Indication
7205 240.544815 May 27, 2020 01:11:59.429966000 CEST 187 2 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) IMSI Detach Indication
7243 240.548250 May 27, 2020 01:11:59.433401000 CEST 2 187 DT1 (BSSMAP) Clear Command
7246 240.548475 May 27, 2020 01:11:59.433626000 CEST 2 187 DT1 (BSSMAP) Clear Command
7266 240.549788 May 27, 2020 01:11:59.434939000 CEST 187 2 DT1 (BSSMAP) Clear Complete
7268 240.549895 May 27, 2020 01:11:59.435046000 CEST 187 2 DT1 (BSSMAP) Clear Complete
7430 250.429439 May 27, 2020 01:12:09.314590000 CEST 127.0.0.1 57511 127.0.0.1 4729 TMSI 0x08dcbc72 yields NRI = 0x372
7431 250.429489 May 27, 2020 01:12:09.314640000 CEST 127.0.0.1 57511 127.0.0.1 4729 NRI 0x372 from TMSI 0x08dcbc72 matches msc 1
7440 250.430125 May 27, 2020 01:12:09.315276000 CEST 187 2 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) Location Updating Request
7441 250.430261 May 27, 2020 01:12:09.315412000 CEST 187 2 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) Location Updating Request
7483 250.432528 May 27, 2020 01:12:09.317679000 CEST 2 187 DT1 (DTAP) (MM) Identity Request
7486 250.432701 May 27, 2020 01:12:09.317852000 CEST 2 187 DT1 (DTAP) (MM) Identity Request
7506 250.900625 May 27, 2020 01:12:09.785776000 CEST 187 2 DT1 (DTAP) (MM) Identity Response
7507 250.900776 May 27, 2020 01:12:09.785927000 CEST 187 2 DT1 (DTAP) (MM) Identity Response
7614 250.918861 May 27, 2020 01:12:09.804012000 CEST 2 187 SACK DT1 (DTAP) (MM) Authentication Request
7615 250.919009 May 27, 2020 01:12:09.804160000 CEST 2 187 SACK DT1 (DTAP) (MM) Authentication Request
7637 252.076891 May 27, 2020 01:12:10.962042000 CEST 187 2 DT1 (DTAP) (MM) Authentication Response
7638 252.076993 May 27, 2020 01:12:10.962144000 CEST 187 2 DT1 (DTAP) (MM) Authentication Response
7666 252.078269 May 27, 2020 01:12:10.963420000 CEST 2 187 SACK DT1 (BSSMAP) Classmark Request
7667 252.078381 May 27, 2020 01:12:10.963532000 CEST 2 187 SACK DT1 (BSSMAP) Classmark Request
7688 252.548548 May 27, 2020 01:12:11.433699000 CEST 187 2 DT1 (BSSMAP) Classmark Update
7689 252.548665 May 27, 2020 01:12:11.433816000 CEST 187 2 DT1 (BSSMAP) Classmark Update
7707 252.549981 May 27, 2020 01:12:11.435132000 CEST 2 187 SACK DT1 (BSSMAP) Cipher Mode Command
7708 252.550063 May 27, 2020 01:12:11.435214000 CEST 2 187 SACK DT1 (BSSMAP) Cipher Mode Command
7728 253.019690 May 27, 2020 01:12:11.904841000 CEST 187 2 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
7729 253.019945 May 27, 2020 01:12:11.905096000 CEST 187 2 DT1 (BSSMAP) Cipher Mode Complete (DTAP) (RR) Ciphering Mode Complete
7807 253.042070 May 27, 2020 01:12:11.927221000 CEST 2 187 SACK DT1 (DTAP) (MM) Identity Request
7808 253.042339 May 27, 2020 01:12:11.927490000 CEST 2 187 SACK DT1 (DTAP) (MM) Identity Request
7828 253.489399 May 27, 2020 01:12:12.374550000 CEST 187 2 DT1 (DTAP) (MM) Identity Response
7829 253.489568 May 27, 2020 01:12:12.374719000 CEST 187 2 DT1 (DTAP) (MM) Identity Response
7857 253.491642 May 27, 2020 01:12:12.376793000 CEST 127.0.0.1 57597 127.0.0.1 4729 New NRI from range [0x200..0x3ff] = 0x3f9 --> TMSI 0xecfe6b19
7866 253.492244 May 27, 2020 01:12:12.377395000 CEST 2 187 SACK DT1 (DTAP) (MM) Location Updating Accept
7867 253.492367 May 27, 2020 01:12:12.377518000 CEST 2 187 SACK DT1 (DTAP) (MM) Location Updating Accept
7886 253.960552 May 27, 2020 01:12:12.845703000 CEST 187 2 DT1 (DTAP) (MM) TMSI Reallocation Complete
7887 253.960723 May 27, 2020 01:12:12.845874000 CEST 187 2 DT1 (DTAP) (MM) TMSI Reallocation Complete
7927 253.966585 May 27, 2020 01:12:12.851736000 CEST 2 187 SACK DT1 (DTAP) (MM) MM Information
7928 253.966630 May 27, 2020 01:12:12.851781000 CEST 2 187 DT1 (BSSMAP) Clear Command
7930 253.966732 May 27, 2020 01:12:12.851883000 CEST 2 187 SACK DT1 (DTAP) (MM) MM Information
7931 253.966767 May 27, 2020 01:12:12.851918000 CEST 2 187 DT1 (BSSMAP) Clear Command
7954 253.968157 May 27, 2020 01:12:12.853308000 CEST 187 2 DT1 (BSSMAP) Clear Complete
7955 253.968236 May 27, 2020 01:12:12.853387000 CEST 187 2 DT1 (BSSMAP) Clear Complete
8279 276.322799 May 27, 2020 01:12:35.207950000 CEST 127.0.0.1 57511 127.0.0.1 4729 TMSI 0x2cfe6b19 yields NRI = 0x3f9
8280 276.322914 May 27, 2020 01:12:35.208065000 CEST 127.0.0.1 57511 127.0.0.1 4729 NRI 0x3f9 from TMSI 0x2cfe6b19 matches msc 1
8286 276.324134 May 27, 2020 01:12:35.209285000 CEST 187 2 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) IMSI Detach Indication
8287 276.324401 May 27, 2020 01:12:35.209552000 CEST 187 2 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) IMSI Detach Indication
8325 276.329599 May 27, 2020 01:12:35.214750000 CEST 2 187 DT1 (BSSMAP) Clear Command
8328 276.329891 May 27, 2020 01:12:35.215042000 CEST 2 187 DT1 (BSSMAP) Clear Command
8348 276.334025 May 27, 2020 01:12:35.219176000 CEST 187 2 DT1 (BSSMAP) Clear Complete
8350 276.334315 May 27, 2020 01:12:35.219466000 CEST 187 2 DT1 (BSSMAP) Clear Complete
8510 290.210265 May 27, 2020 01:12:49.095416000 CEST 127.0.0.1 57511 127.0.0.1 4729 TMSI 0xa55ded22 yields NRI = 0x177
8511 290.210341 May 27, 2020 01:12:49.095492000 CEST 127.0.0.1 57511 127.0.0.1 4729 NRI 0x177 from TMSI 0xa55ded22 matches msc 0
8517 290.211026 May 27, 2020 01:12:49.096177000 CEST 187 1 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) IMSI Detach Indication
8518 290.211181 May 27, 2020 01:12:49.096332000 CEST 187 1 CR (BSSMAP) Complete Layer 3 Information (DTAP) (MM) IMSI Detach Indication
8556 290.214603 May 27, 2020 01:12:49.099754000 CEST 1 187 DT1 (BSSMAP) Clear Command
8559 290.214779 May 27, 2020 01:12:49.099930000 CEST 1 187 DT1 (BSSMAP) Clear Command
8579 290.216591 May 27, 2020 01:12:49.101742000 CEST 187 1 DT1 (BSSMAP) Clear Complete
8581 290.216751 May 27, 2020 01:12:49.101902000 CEST 187 1 DT1 (BSSMAP) Clear Complete
Updated by neels almost 4 years ago
- Checklist item VTY configuration of number of TMSI bits reserved for NRI set to Done
- Checklist item VTY configuration of NRI <-> MSC SCCP address mappings set to Done
- Checklist item ability to establish A to multiple MSCs simultaneously set to Done
- Checklist item NAS Node Selection Function set to Done
Updated by neels almost 4 years ago
- Checklist item ensure NULL-NRI config and behavior added
Updated by fixeria almost 4 years ago
But I do notice that phones tend to pass their previous TMSI even to completely unknown PLMNs.
Updated by ipse almost 4 years ago
neels Do you think there is a way to add counters to this code to see whether the pooling works correctly when running in a production setting? I.e. with too many connections to check them manually. Maybe count the number of connections routed towards each MSC to see the load proportion between the MSCs?
Updated by neels almost 4 years ago
- Checklist item add counters for MSC pooling added
ipse wrote:
neels Do you think there is a way to add counters to this code
Of course there is a way, very simple to implement that.
Updated by neels almost 4 years ago
I am focusing back on ttcn3 testing of MSC pooling.
I have managed to configure three A links in the ttcn3, in a way that the current tests all still pass.
I have also managed to write a Location Updating test.
Now I have two initial goals that will open the way for proper tests, which I am unable to reach:
1: Run three consecutive Location Updating with IMSI MI, where only one MSC is connected. The MSC should stay connected for the duration of the test.
All three LU should end up on the first BSSAP link.
2: Run three consecutive Location Updating with IMSI MI, with three MSC connected. Also the MSCs should stay connected.
Each BSSAP link should get one of the Location Updating (round robin).
If these succeed, I have the necessary basis for also testing distribution by NRI (TMSI MI) and matching Paging Response to the MSC that originally paged.
But I can't get it to work. Status:
1: Three LU on the same MSC.¶
I have this function, which works:
(also found on osmo-ttcn3-hacks branch neels/mscpool)
private function f_perform_location_updating(template MobileIdentityLV mi := omit) runs on MSC_ConnHdlr {
timer T := 10.0;
if (not ispresent(mi)) {
mi := ts_MI_IMSI_LV(g_pars.imsi);
}
var PDU_ML3_MS_NW l3_info := valueof(ts_LU_REQ(LU_Type_IMSI_Attach, valueof(mi)));
var octetstring l3_enc := enc_PDU_ML3_MS_NW(l3_info);
f_logp("establish channel, send Location Update Request");
f_create_bssmap_exp(l3_enc);
RSL_Emulation.f_chan_est(g_pars.ra, l3_enc, g_pars.link_id, g_pars.fn);
f_logp("expect BSSAP Location Update Request at MSC");
var template PDU_BSSAP exp_l3_compl;
exp_l3_compl := tr_BSSMAP_ComplL3()
if (g_pars.aoip == false) {
exp_l3_compl.pdu.bssmap.completeLayer3Information.codecList := omit;
} else {
exp_l3_compl.pdu.bssmap.completeLayer3Information.codecList := ?;
}
var PDU_BSSAP bssap;
T.start;
alt {
[] BSSAP.receive(exp_l3_compl) -> value bssap {
f_logp("received expected Location Update Request at MSC");
log("rx exp_l3_compl = ", bssap);
}
[] BSSAP.receive(tr_BSSMAP_ComplL3) {
Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, "Received non-matching COMPLETE LAYER 3 INFORMATION");
}
[] T.timeout {
Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, "Timeout waiting for COMPLETE LAYER 3 INFORMATION");
}
}
/* start ciphering, if requested */
if (ispresent(g_pars.encr)) {
f_logp("start ciphering");
f_cipher_mode(g_pars.encr.enc_alg, g_pars.encr.enc_key);
}
/*
f_logp("accept LU from MSC");
BSSAP.send(ts_PDU_DTAP_MT(ts_LU_ACCEPT));
f_logp("see LU acceptance on RSL");
var RSL_Message rsl;
RSL.receive(tr_RSL_DATA_REQ(g_chan_nr)) -> value rsl {
var PDU_ML3_NW_MS l3 := dec_PDU_ML3_NW_MS(rsl.ies[2].body.l3_info.payload);
f_logp("Rx RSL_DATA_REQ");
log("Rx L3 from net: ", l3);
if (ischosen(l3.msgs.mm.locationUpdateAccept)) {
f_logp("received expected LU Accept on RSL");
setverdict(pass);
} else {
Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, log2str("Unexpected L3 received", l3));
f_logp("Unexpected L3 received");
}
}
*/
f_logp("MSC instructs BSC to clear channel");
BSSAP.send(ts_BSSMAP_ClearCommand(0));
interleave {
[] RSL.receive(tr_RSL_DATA_REQ(g_chan_nr, ?, decmatch tr_RRM_RR_RELEASE)) {
f_logp("Got RSL RR Release");
}
[] RSL.receive(tr_RSL_DEACT_SACCH(g_chan_nr)) {
f_logp("Got RSL Deact SACCH");
}
[] BSSAP.receive(tr_BSSMAP_ClearComplete) {
f_logp("Got BSSMAP Clear Complete");
}
[] RSL.receive(tr_RSL_MsgTypeD(RSL_MT_RF_CHAN_REL)) {
f_logp("Got RSL RF Chan Rel, sending Rel Ack");
RSL.send(ts_RSL_RF_CHAN_REL_ACK(g_chan_nr));
}
}
}
private function f_tc_location_updating_by_imsi(charstring id) runs on MSC_ConnHdlr {
f_MscConnHdlr_init(g_pars.media_nr, "127.0.0.2", "127.0.0.3", FR_AMR);
f_perform_location_updating(ts_MI_IMSI_LV(g_pars.imsi));
}
I can run a test like this, successfully:
testcase TC_location_updating_by_imsi_on_1_msc() runs on test_CT {
var MSC_ConnHdlr vc_conn;
var TestHdlrParams pars := f_gen_test_hdlr_pars();
f_init(1, true);
f_sleep(1.0);
pars.imsi := '001010000000001'H;
vc_conn := f_start_handler(refers(f_tc_location_updating_by_imsi), pars, bssap_idx := 0);
vc_conn.done;
}
Now I tried to call this three times in sequence. First I tried to call f_perform_location_updating() thrice in the same f_tc_:
private function f_tc_location_updating_by_imsi(charstring id) runs on MSC_ConnHdlr {
f_MscConnHdlr_init(g_pars.media_nr, "127.0.0.2", "127.0.0.3", FR_AMR);
f_perform_location_updating(ts_MI_IMSI_LV('001010000000001'H));
f_perform_location_updating(ts_MI_IMSI_LV('001010000000002'H));
f_perform_location_updating(ts_MI_IMSI_LV('001010000000003'H));
}
The first LU is going well all the way, concluding with Clear Command and Clear Complete.
Then the second LU starts out fine by sending the MS DTAP through to the MSC on BSSAP.
Now when responding to that from the ttcn3 MSC, I face the problem that the SCCP response still yields the local reference of the first LU run.
I gather that each MSC_ConnHandler is intended to run only one SCCP connection. So, another attempt like this:
testcase TC_location_updating_by_imsi_on_1_msc() runs on test_CT {
var MSC_ConnHdlr vc_conn;
var TestHdlrParams pars := f_gen_test_hdlr_pars();
f_init(1, true);
f_sleep(1.0);
pars.imsi := '001010000000001'H;
vc_conn := f_start_handler(refers(f_tc_location_updating_by_imsi), pars, bssap_idx := 0);
vc_conn.done;
// f_init(1, true);
f_sleep(1.0);
pars.imsi := '001010000000002'H;
vc_conn := f_start_handler(refers(f_tc_location_updating_by_imsi), pars, bssap_idx := 0);
vc_conn.done;
// f_init(1, true);
f_sleep(1.0);
pars.imsi := '001010000000003'H;
vc_conn := f_start_handler(refers(f_tc_location_updating_by_imsi), pars, bssap_idx := 0);
vc_conn.done;
}
This results in:
IPA0-RSL-RSL(9)@5d5496b6a833: Dynamic test case error: Data cannot be sent on port CLIENT_PT to component 10 because there is no connection towards component 10. IPA0-RSL-IPA(8)@5d5496b6a833: Dynamic test case error: Port IPA_RSL_PORT has neither connections nor mappings. Message cannot be sent on it. (Operation now in progress)
2: Run three LU round robin across three MSC.¶
To get the second MSC_ConnHandler to communicate with osmo-bsc, I figured out that I also need to edit the osmo-stp.cfg according to how it is done in MSC_Tests.ttcn:
cs7 instance 0 xua rkm routing-key-allocation dynamic-permitted asp virt-msc0-0 23905 2905 m3ua local-ip 172.18.2.200 remote-ip 172.18.2.203 as mahlzeit ipa routing-key 0 0.23.4 point-code override dpc 0.23.1 as virt-msc0 m3ua asp virt-msc0-0 routing-key 1 0.23.1 asp virt-msc1-0 23906 2905 m3ua local-ip 172.18.2.200 remote-ip 172.18.2.203 as virt-msc1 m3ua asp virt-msc1-0 routing-key 2 0.0.2 asp virt-msc2-0 23907 2905 m3ua local-ip 172.18.2.200 remote-ip 172.18.2.203 as virt-msc2 m3ua asp virt-msc2-0 routing-key 3 0.0.3 route-table system update route 0.23.1 7.255.7 linkset virt-msc0 update route 0.0.2 7.255.7 linkset virt-msc1 update route 0.0.3 7.255.7 linkset virt-msc2
This enables routing to and back from the second MSC_ConnHandler and the RESET -> RESET-ACK works on the second A link.
The test is configured to connect two MSCs now, and both RESET-ACK fine.
To get the LU sent to the second MSC, I need to make the round-robin pass the first MSC, so I first run a LU on the first MSC, then try to get one through on the second MSC:
private function f_tc_location_updating_by_imsi_on_3_msc(charstring id) runs on MSC_ConnHdlr {
f_MscConnHdlr_init(g_pars.media_nr, "127.0.0.2", "127.0.0.3", FR_AMR);
f_perform_location_updating(ts_MI_IMSI_LV(g_pars.imsi));
}
testcase TC_location_updating_by_imsi_on_3_msc() runs on test_CT {
f_init(1, true, nr_msc := 2);
f_sleep(1.0);
var MSC_ConnHdlr vc_conn1;
var TestHdlrParams pars1 := f_gen_test_hdlr_pars(bssap_idx := 0);
pars1.imsi := '001010000000001'H;
vc_conn1 := f_start_handler(refers(f_tc_location_updating_by_imsi_on_3_msc), pars1, bssap_idx := 0);
vc_conn1.done;
var MSC_ConnHdlr vc_conn2;
var TestHdlrParams pars2 := f_gen_test_hdlr_pars();
pars2.imsi := '001010000000002'H;
vc_conn2 := f_start_handler(refers(f_tc_location_updating_by_imsi_on_3_msc), pars2, bssap_idx := 1);
vc_conn2.done;
}
But then, again, I hit the same problem as above:
IPA0-RSL-RSL(12)@7377ca6a83e2: Dynamic test case error: Data cannot be sent on port CLIENT_PT to component 13 because there is no connection towards component 13. IPA0-RSL-IPA(11)@7377ca6a83e2: Dynamic test case error: Port IPA_RSL_PORT has neither connections nor mappings. Message cannot be sent on it. (Operation now in progress)
It seems to me that the RSL port is also duplicated when having two MSC_ConnHandlers, which is not what I intend.
How can I resolve this?
Updated by neels almost 4 years ago
Indeed, the test with multiple MSCs works as soon as I send the second MSC's RSL part on the first MSC_ConnHandler, and do its BSSAP part on the second MSC_ConnHandler.
That is suboptimal:
Ideally, I would like to write, in pseudocode:
RSL.send(ts_LU_REQ(IMSI_1)) bssap[0].receive(l3_complete) RSL.send(ts_LU_REQ(IMSI_2)) bssap[1].receive(l3_complete)
Since it is on different MSC_ConnHandlers, I'd like to write
f_lu_1() {
RSL.send(ts_LU_REQ(IMSI_1))
bssap[0].receive(l3_complete)
}
f_lu_2() {
RSL.send(ts_LU_REQ(IMSI_2))
bssap[1].receive(l3_complete)
}
But now it seems that I have to write:
f_lu_1() {
RSL.send(ts_LU_REQ(IMSI_1))
bssap[0].receive(l3_complete)
RSL.send(ts_LU_REQ(IMSI_2))
}
f_lu_2() {
bssap[1].receive(l3_complete)
}
in real working code:
private function f_perform_location_updating_rsl(template MobileIdentityLV mi := omit) runs on MSC_ConnHdlr {
timer T := 10.0;
if (not ispresent(mi)) {
mi := ts_MI_IMSI_LV(g_pars.imsi);
}
var PDU_ML3_MS_NW l3_info := valueof(ts_LU_REQ(LU_Type_IMSI_Attach, valueof(mi)));
var octetstring l3_enc := enc_PDU_ML3_MS_NW(l3_info);
f_logp("establish channel, send Location Update Request");
f_create_bssmap_exp(l3_enc);
RSL_Emulation.f_chan_est(g_pars.ra, l3_enc, g_pars.link_id, g_pars.fn);
f_logp("see LU acceptance on RSL");
var RSL_Message rsl;
RSL.receive(tr_RSL_DATA_REQ(g_chan_nr)) -> value rsl {
var PDU_ML3_NW_MS l3 := dec_PDU_ML3_NW_MS(rsl.ies[2].body.l3_info.payload);
f_logp("Rx RSL_DATA_REQ");
log("Rx L3 from net: ", l3);
if (ischosen(l3.msgs.mm.locationUpdateAccept)) {
f_logp("received expected LU Accept on RSL");
setverdict(pass);
} else {
Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, log2str("Unexpected L3 received", l3));
f_logp("Unexpected L3 received");
}
}
interleave {
[] RSL.receive(tr_RSL_DATA_REQ(g_chan_nr, ?, decmatch tr_RRM_RR_RELEASE)) {
f_logp("Got RSL RR Release");
}
[] RSL.receive(tr_RSL_DEACT_SACCH(g_chan_nr)) {
f_logp("Got RSL Deact SACCH");
}
[] RSL.receive(tr_RSL_MsgTypeD(RSL_MT_RF_CHAN_REL)) {
f_logp("Got RSL RF Chan Rel, sending Rel Ack");
RSL.send(ts_RSL_RF_CHAN_REL_ACK(g_chan_nr));
}
}
setverdict(pass);
f_sleep(1.0);
}
private function f_perform_location_updating_bssap(template MobileIdentityLV mi := omit) runs on MSC_ConnHdlr {
timer T := 10.0;
if (not ispresent(mi)) {
mi := ts_MI_IMSI_LV(g_pars.imsi);
}
var PDU_ML3_MS_NW l3_info := valueof(ts_LU_REQ(LU_Type_IMSI_Attach, valueof(mi)));
var octetstring l3_enc := enc_PDU_ML3_MS_NW(l3_info);
f_logp("expect BSSAP Location Update Request at MSC");
f_create_bssmap_exp(l3_enc);
var template PDU_BSSAP exp_l3_compl;
exp_l3_compl := tr_BSSMAP_ComplL3()
if (g_pars.aoip == false) {
exp_l3_compl.pdu.bssmap.completeLayer3Information.codecList := omit;
} else {
exp_l3_compl.pdu.bssmap.completeLayer3Information.codecList := ?;
}
var PDU_BSSAP bssap;
T.start;
alt {
[] BSSAP.receive(exp_l3_compl) -> value bssap {
f_logp("received expected Location Update Request at MSC");
log("rx exp_l3_compl = ", bssap);
}
[] BSSAP.receive(tr_BSSMAP_ComplL3) {
Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, "Received non-matching COMPLETE LAYER 3 INFORMATION");
}
[] T.timeout {
Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, "Timeout waiting for COMPLETE LAYER 3 INFORMATION");
}
}
f_logp("accept LU from MSC");
BSSAP.send(ts_PDU_DTAP_MT(ts_LU_ACCEPT));
f_logp("MSC instructs BSC to clear channel");
BSSAP.send(ts_BSSMAP_ClearCommand(0));
BSSAP.receive(tr_BSSMAP_ClearComplete) {
f_logp("Got BSSMAP Clear Complete");
};
setverdict(pass);
f_sleep(1.0);
}
private function f_tc_location_updating_by_imsi_on_3_msc_1(charstring id) runs on MSC_ConnHdlr {
f_MscConnHdlr_init(g_pars.media_nr, "127.0.0.2", "127.0.0.3", FR_AMR);
f_perform_location_updating(ts_MI_IMSI_LV(g_pars.imsi));
f_perform_location_updating_rsl(ts_MI_IMSI_LV('001010000000002'H)); // <--- for second MSC
}
private function f_tc_location_updating_by_imsi_on_3_msc_2(charstring id) runs on MSC_ConnHdlr {
f_MscConnHdlr_init(g_pars.media_nr, "127.0.0.2", "127.0.0.3", FR_AMR);
f_perform_location_updating_bssap(ts_MI_IMSI_LV(g_pars.imsi));
}
testcase TC_location_updating_by_imsi_on_3_msc() runs on test_CT {
f_init(1, true, nr_msc := 2);
f_sleep(1.0);
var MSC_ConnHdlr vc_conn1;
var TestHdlrParams pars1 := f_gen_test_hdlr_pars(bssap_idx := 0);
pars1.imsi := '001010000000001'H;
vc_conn1 := f_start_handler(refers(f_tc_location_updating_by_imsi_on_3_msc_1), pars1, bssap_idx := 0);
var MSC_ConnHdlr vc_conn2;
var TestHdlrParams pars2 := f_gen_test_hdlr_pars();
pars2.imsi := '001010000000002'H;
vc_conn2 := f_start_handler(refers(f_tc_location_updating_by_imsi_on_3_msc_2), pars2, bssap_idx := 1);
vc_conn1.done;
vc_conn2.done;
}
Updated by laforge almost 4 years ago
On Thu, Jun 04, 2020 at 01:36:28AM +0000, neels [REDMINE] wrote:
Now I tried to call this three times in sequence. First I tried to call f_perform_location_updating() thrice in the same f_tc_:
> private function f_tc_location_updating_by_imsi(charstring id) runs on MSC_ConnHdlr { > f_MscConnHdlr_init(g_pars.media_nr, "127.0.0.2", "127.0.0.3", FR_AMR); > f_perform_location_updating(ts_MI_IMSI_LV('001010000000001'H)); > f_perform_location_updating(ts_MI_IMSI_LV('001010000000002'H)); > f_perform_location_updating(ts_MI_IMSI_LV('001010000000003'H)); > } >
In theory this should work. If it is not, it looks like a bug in the TTCN3 test infrastructure
code, most likely the RAN emulation or the test cases. At least architecturally, there is
no reason why it shouldn't work, IMHO.
The first LU is going well all the way, concluding with Clear Command and Clear Complete.
The question is: Is the SCCP connection also clsoed? The ClearCommand/Complete is on BSSMAP
level. But is the underlying SCCP connection closed? If there is not either an inbound
disconnect from the BSC [yet?] or no outbound disconnect from the simulated MSC, then that
connection stays lingering, and the RAN_Emulation will retain the mapping of that SCCP
connectio to your ConnHdlr component.
Then the second LU starts out fine by sending the MS DTAP through to the MSC on BSSAP.
good.
Now when responding to that from the ttcn3 MSC, I face the problem that the SCCP response still yields the local reference of the first LU run.
This can IMHO only happen if the old SCCP connection has not been closed, and the RAN_Emulation
hence never calls f_conn_tabel_del() for the connectionID of the first SCCP connection.
I gather that each MSC_ConnHandler is intended to run only one SCCP connection.
There is nothing intrinsic from an architectural point that should require that. You cannot
have multiple concurrent SCCP connections, but you should be able to have multiple sequential
SCCP connections from one ConnHdlr instance.
Updated by neels almost 4 years ago
I have some success:
- It was indeed the missing SCCP RLSD that failed to let 3 LUs run in sequence on one MSC.
- For three separate MSCs, when I run each LU on a separate RSL (!), things work there. That deserves another close look as to why that happens.
Also, only the first run is able to do a full LU Accept, the second and third only work when directly Clearing after the LU Request.
So, both tests pass now, though it could use some review.
The working patch is here, note the FIXME comments:
http://git.osmocom.org/osmo-ttcn3-hacks/commit/?h=neels/mscpool&id=d0b13e1df37e5e30d8d68e54c41ce6f9febc35e9
(Testing whether certain NRI are forwarded to the correct MSC is not yet implemented, but I hope will be just a permutation of above patch)
This test depends on patches in various repositories, all of them on branch neels/mscpool: libosmocore, libosmo-sccp, osmo-bsc and osmo-ttcn3-hacks, docker-playground (only "bsc: adjust cfg for multiple MSCs, msc: tweak comments in cfg").
Updated by neels almost 4 years ago
I'm having another ttcn3 problem concerning Paging testing.
I need to test that, after an MSC sent a Paging, the Paging Response goes back to the same MSC.
So I need to send a Paging from BSSAP, and then a Paging Response from RSL, without any BSSAP Reset happening in-between.
The problem is that our test setup apparently cannot do Paging and Paging Response in the same test.
All our osmo-bsc Paging tests call f_init() with handler_mode false, and set off the Paging UnitData from the test_CT.
As soon as I call f_init() with handler_mode true, sending a Paging like that no longer seems to work.
At the same time, if I want to send a Paging Response and handle it on the MSC side via an MSC_ConnHdlr, I apparently need to f_init() with handler_mode true.
As soon as I call f_init() with handler_mode false, starting up the MSC_ConnHdlr no longer seems to work.
What I need, in pseudocode, is one of:
f_tc_paging() runs on MSC_ConnHdlr {
BSSAP.send(ts_Unitdata(Paging(tmsi)))
RSL.receive(tr_PagingCmd)
RSL.send(ts_PagingResponse(tmsi))
BSSAP.receive(tr_BSSMAP_ComplL3(tr_PagingResponse(tmsi)))
}
TC_paging() runs on test_CT {
f_start_handler(f_tc_paging);
}
f_tc_paging() runs on MSC_ConnHdlr {
RSL.send(ts_PagingResponse(tmsi))
BSSAP.receive(tr_BSSMAP_ComplL3(tr_PagingResponse(tmsi)))
}
TC_paging() runs on test_CT {
BSSAP.send(ts_Unitdata(Paging(tmsi)))
f_exp_ipa_rx(0, tr_PagingCmd)
f_start_handler(f_tc_paging);
}
TC_paging() runs on test_CT {
BSSAP.send(ts_Unitdata(Paging(tmsi)))
f_exp_ipa_rx(0, tr_PagingCmd)
RSL.send(ts_PagingResponse(tmsi))
BSSAP.receive(tr_BSSMAP_Connect(tr_PagingResponse(tmsi)))
}
I currently don't know how to achieve this...
Feeble real code attempts can be found here: http://git.osmocom.org/osmo-ttcn3-hacks/commit/?h=neels/mscpool&id=b5add2478d4d37d52d842c19e2f25f1cdc92a2a4
(that's osmo-ttcn3-hacks patch "WIP paging testing" on branch neels/mscpool)
Updated by neels almost 4 years ago
- Checklist item storing of Global-CN-ID when receiving paging from MSC; routing paging response to that Global-CN-ID set to Done
- Checklist item figure out how to test with multiple MSCs in ttcn-bsc-tests set to Done
- Checklist item ensure NULL-NRI config and behavior set to Done
Updated by neels almost 4 years ago
- Checklist item ttcn3 tests added
- Checklist item code review and merge patches added
- % Done changed from 70 to 90
Solved the Paging problem by adding BSSAP_N_UNITDATA_req to RAN_Conn_PT.
All ttcn3 tests are now implemented and pass.
Updated by neels almost 4 years ago
- Checklist item ttcn3 tests set to Not done
- % Done changed from 90 to 80
apparently my changes to the test suite are producing some fallout in non-mscpool tests. need to investigate and fix.
Updated by neels almost 4 years ago
I was thinking about the fact that phones often send the TMSI they previously used to a completely different network.
This makes it appear to an MSC pool that an NRI has already been assigned, and the round robin does not take effect.
However, upon IMSI attach, there is information about the previous LAI. If it mismatches the BSC's PLMN code, we should disregard the TMSI.
Updated by laforge almost 4 years ago
On Thu, Jun 11, 2020 at 01:12:36AM +0000, neels [REDMINE] wrote:
I was thinking about the fact that phones often send the TMSI they previously used to a completely different network.
This makes it appear to an MSC pool that an NRI has already been assigned, and the round robin does not take effect.
However, upon IMSI attach, there is information about the previous LAI. If it mismatches the BSC's PLMN code, we should disregard the TMSI.
very good point, and I agree.
Updated by neels over 3 years ago
- Checklist item add counters for MSC pooling set to Done
- Checklist item ttcn3 tests set to Done
- Checklist item code review and merge patches set to Done
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
my bad for not updating this issue. All implemented and merged.
