Feature #3682
closedIntra-domain connection of OsmoBSC to multiple MSCs
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
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 almost 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 almost 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 almost 4 years ago
- Related to Feature #4472: Intra-domain connection of OsmoGBPROXY to multiple SGSNs (pooling) added
Updated by laforge almost 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 robin
Below 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.