Cellular Network Infrastructure » Radio Access Network » OsmoBTS

A patch for osmo-bts can be found here:

https://gerrit.osmocom.org/c/osmo-bts/+/31600 pcuif_proto: version 11: rework sending IMM ASS over PCH [WIP]

Some highlights (proposed changes):

• Remove PCU_IF_MSG_DATA_CNF_DT, there is already PCU_IF_MSG_DATA_CNF which already contains the TLLI;
• Remove PCU_IF_SAPI_AGCH_DT, DATA.req with PCU_IF_SAPI_PCH contains the TLLI now;
• struct gsm_pcu_if_data_cnf: remove meaningless fields like lqual_cb and arfcn (why would they be present in CNF?!?);
• struct gsm_pcu_if_data_cnf: add padding after sapi to facilitate aligned access;
• struct gsm_pcu_if_pch_data: new structure, which is included in DATA.req with SAPI=PCU_IF_SAPI_PCH;
• struct gsm_pcu_if_pch_data: this structure carries IMSI % 1000 (needed for paging group calculation);

I have looked once more at the osmo-bts patch from fixeria, I have annotated some locations that need updating since the PCUIF interface has changed.

When updating the related TTCN3 tests we need to regard the following changes in the messages that are passed along:

• no change: macblock
• added: tlli, imsi

• no change: fn
• added: tlli
• removed: macblock

The following two patches are currently still in review, there are also open comments that need to be fixed

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32606 PCUIF_Types: add record PCUIF_pch_dt
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32607 PCUIF_Types: add templates for PCU_IF_MSG_DATA_CNF_DT message types

There has been some confusion about which PCH message types should be confirmed and which not. OsmoBTS currently confirms PAGING COMMAND and IMMEDIATE ASSIGNMENT messages, but OsmoPCU ignores the confirmation of PAGIGN COMMAND messages. This is a bit confusing, OsmoBTS should only confirm PAGING COMMAND messages of course. We also need to clean up the code a bit so that switching to the newer direct TLLI based interface becomes easier.

There are two patches that clean up the PCUIF problems in OsmoBTS:
https://gerrit.osmocom.org/c/osmo-bts/+/32733 paging: parse PCUIF data indication outside of paging.c
https://gerrit.osmocom.org/c/osmo-bts/+/32734 paging: do not confirm PAGING COMMAND messages

In OsmoBSC we still use the old and the newer direct TLLI based interface in parallel. This should be cleaned up so that we only use the direct TLLI based interface. We also need to fix the coresponding part in OsmoPCU as well.
https://gerrit.osmocom.org/c/osmo-bsc/+/32693 pcu_sock: fix PCUIF interface (PCH)
https://gerrit.osmocom.org/c/osmo-pcu/+/32694 gprs_rlcmac: also use PCU_IF_SAPI_PCH_DT for paging MAC blocks

Once those patches are merged we are ready to add migrate OsmoBTS (and the related TTCN3 tests)

osmo-bsc now only uses the more recent direct TLLI based interface. To make sure everything is fine I also have tested it on real hardware once more. This also means that the PCUIF API is now cleanly used. We either use the direct TLLI based interface (osmo-bsc) or the old interface that that sends the whole MAC block back for confirmation.

There are still two patches for OsmoBTS in review:
https://gerrit.osmocom.org/c/osmo-bts/+/32733 paging: parse PCUIF data indication outside of paging.c
https://gerrit.osmocom.org/c/osmo-bts/+/32734 paging: do not confirm PAGING COMMAND messages

Once those patches are merged we are ready to migrate OsmoBTS (and the related TTCN3 tests)

The two patches from above are still in review:

https://gerrit.osmocom.org/c/osmo-bts/+/32733 paging: parse PCUIF data indication outside of paging.c
https://gerrit.osmocom.org/c/osmo-bts/+/32734 paging: do not confirm PAGING COMMAND messages

Since we are not under pressure with this, I think it is the best to get those two patches merged before we continue.

The two cleanup patches (above) have been merged, so we are now ready to move to PCUIF v.11.

The following two patches complete the PCUIF v.11 support for the OsmoBTS testsuite. After the change the testsuite is still compatible with older OsmoBTS versions

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33417 PCUIF_Types: fix record PCUIF_pch_dt
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33418 BTS_Tests: Add support for PCUIF protocol version 11

The changes to the TTCN3 testsuite changes and the configuration changes to docker playground have made it into master. Unfortunately we still miss the changes for osmo-bts, this means that all testcases that touch the PCUIF interface now fail. The problem should vanish once the osmo-bts changes are merged with the following patch:

https://gerrit.osmocom.org/c/osmo-bts/+/33522

We plan to retain the support for v.10 in OsmoPCU in the next release. This also means that we can safely switch the tests to v.11 after the release. Mechanisms to support both versions at the same time are not needed then. When this is done we can finally drop the support for v.10 in current master.

Unfortunately recently a problem with IMMEDIATE ASSIGNMENT for downlink paging group calculation popped up. It is a rare scenario, but it may happen that a downlink TBF must be assigned before the MS has completed the GMM ATTACH REQUEST. In this phase the IMSI is not known to the PCU, so it will send an empty IMSI string to the BTS. The BTS then would just use paging group 0. This still works since in the GMM ATTACH REQUEST phase the MS is still in non-DRX mode and is listening to all CCCH blocks. This also includes the PCH at paging group 0. However, this solves the problem in a sub-optimal way. We might also send the IMMEDIATE ASSIGNMENT through the AGCH and benefit from the lower scheduling latency. This would actually the proper way to do it.

The following patch is currently in review:
https://gerrit.osmocom.org/c/osmo-bts/+/33829 pcu_sock: forward downlink IMMEDAITE ASSIGNMENT with no IMSI to AGCH

In this patch we silently re-direct the IMMEDIATE ASSIGNMENT to the AGCH. This is essentially a work-around and not a proper solution. The PCU is the entity that is in charge here. The decision that the IMMEDIATE ASSIGNMENT should be sent through the AGCH should be made by the PCU and the PCU should pick the correct SAPI. Unfortunately SAPI PCU_IF_SAPI_AGCH just takes MAC blocks and if we use it, the BTS does not have the TLLI to confirm the MAC block. This is where things become a little bit difficult:

The solution would be to add another SAPI PCU_IF_SAPI_AGCH_DT, that works just like PCU_IF_SAPI_AGCH_PCH_DT. Then it is no problem for the receiving entity (osmo-bts, or osmo-bsc) to confirm the IMMEDIATE ASSIGNMENT using the attached TLLI. We may also confirm downlink and uplink IMMEDIATE ASSIGNMENT messages. For downlink it is a strict requirement. If we do the confirmation for uplink as well we might be able to optimize the timing at the PCU as well.

Unfortunately making changes to the PCUIF is complex. I will go through the patches step by step and describe what they do:

At first we add the required PCUIF extensions and the required logic (decide if we use PCH or AGCH) to osmo-pcu. This change will only affect the PCUIF v.11 parts:
https://gerrit.osmocom.org/c/osmo-pcu/+/34058 pcu_l1_if: add support for PCU_IF_SAPI_AGCH_DT for PCUIF v.11

Next we upgrade osmo-bts and osmo-pcu so that they can receive the SAPI PCU_IF_SAPI_AGCH_DT. Since we want to send confirmations. We must also touch the agch queue in bts.c. It makes no sense to keep SAPI PCU_IF_SAPI_AGCH since in PCUIF v.11 osmo-pcu does not use it anymore.

https://gerrit.osmocom.org/c/osmo-bts/+/34059 pcu_sock: use PCU_IF_SAPI_AGCH_DT instead PCU_IF_SAPI_AGCH
https://gerrit.osmocom.org/c/osmo-bsc/+/34060 pcu_sock: use PCU_IF_SAPI_AGCH_DT instead PCU_IF_SAPI_AGCH

The TTCN3 tests need to be upgraded as well. For the BTS tests 34066 and 34067 are the relevant patches. The patches after that are relevant for the PCU test. In case of the PCU tests the strategy is still to wait until the next release and then go the final step.

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34061 BTS_Tests: call f_pcu_data_req with correct timeslot [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34062 BTS_Tests: fix comment [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34063 PCUIF_CodecPort: mention channel (PCH) in log lines [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34064 BTS_Tests: fix log line (AGCH->PCH) [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34065 BTS_Tests: rewrite outdated comment [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34066 PCUIF: Add support for PCU_IF_SAPI_AGCH_DT [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34067 BTS_Tests: add new testcase TC_pcu_data_req_imm_ass_agch [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34068 PCUIF_Components: add compatibility for PCU_IF_SAPI_AGCH_DT [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33796 PCU_Tests: use PCUIF v.11 exclusively [WIP]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34069 WIP: fixup for PCU_Tests: use PCUIF v.11 exclusively [NEW]

There are still two things I am still not happy with:

The first is that at the osmo-bts/osmo-bsc side we look into the MAC block to determine whether the message is an IMMEDIATE ASSIGNMENT (means we have to send a confirmation) or not. This is a bit unclean I think. What we might do here is to fill the tlli field GSM_RESERVED_TMSI in case we do not need a confirmation. This would moves the decision closer to the PCU where it should be and we do not have to look into the MAC block anymore.

The second thing is that in struct gsm_pcu_if_data_cnf_dt we have a lot of unused members. We only need sapi and tlli here. (I have checked fn, it is only used for logging in osmo-pcu). Those fields should be removed in PCUIF v.11.

However, those last two things can be done when the PCU_IF_SAPI_AGCH_DT patches are merged.

dexter as discussed please drop the "_DT" suffix in favour of "2", since it's not "Direct TLLI" and that kind of suffix only causes confusion. Having a "2" suffix clearly states that the one without "2" is to be deprecated in favour of the "2" version, and that they are not used at the same time.

I have checked back the patches above. There was only one patch with reviews in the osmo-ttcn3-hacks patchset, all others have +1 and some even +2. Since the patches largely depend on each other we can not merge the +2 ones yet since the corresponding patches in the other repositories are not ready yet.

Most of the pending patches made it into master. What is still left are the patches that rename the _dt/_DT.

If PCU sends a Paging Request, it would set the "bool confirm" field to false, since it won't need it, so problem resolved. I don't see why you changed the other stuff, it was just about adding a bool so that the BTS/BSC use that to know when to send a confirmation, which has the good side of decoupling that from the specific PCU implementation (one PCU version may decide to receive more confirmations in the future).

Please keep the other stuff as it was, simply add a "bool confirm" which is used at BTS/BSC to know when to confirm upon scheduling.

As discussed in gerrit I have now renamed the flag to "confirm". I also think this is better. I have added some logic to osmo-bsc to catch the corner cases that do not make sense and print an error message in those cases. (I don't think it is a good idea to introduce hacks into osmo-bsc so that the "illegal" cases work as well.)

I have also re-based+fixed the patchset that adds the new SAPI PCU_IF_SAPI_AGCH_2. This now allows us to get confirmations for AGCH MAC blocks as well:

https://gerrit.osmocom.org/c/osmo-pcu/+/34058 pcu_l1_if: add support for PCU_IF_SAPI_AGCH_2 for PCUIF v.11
https://gerrit.osmocom.org/c/osmo-bsc/+/34060 pcu_sock: use PCU_IF_SAPI_AGCH_2 instead PCU_IF_SAPI_AGCH
https://gerrit.osmocom.org/c/osmo-bts/+/34059 pcu_sock: use PCU_IF_SAPI_AGCH_2 instead PCU_IF_SAPI_AGCH

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34208 GPRS_Components: remove excess new-line
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34066 PCUIF: Add support for PCU_IF_SAPI_AGCH_2
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34209 BTS_Tests: use f_PCUIF_tx_mac_block_agch in TC_pcu_data_req_agch [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34067 BTS_Tests: add new testcase TC_pcu_data_req_imm_ass_agch
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34068 PCUIF_Components: add compatibility for PCU_IF_SAPI_AGCH_2
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33796 PCU_Tests: use PCUIF v.11 exclusively [WIP]

I have also thought a bit about the identifier problem that we have when no TLLI is assigned yet. I have created a new ticket for this, so we can discuss the problem there: #6150

I have now re-based all patches above and fixed all the review issues that were there. As far as I can see we should be done and ready for making a new release when those patches are merged. The only exception is [1], which should be merged shortly after the new release.

[1] https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33796 PCU_Tests: use PCUIF v.11 exclusively [WIP]

As far as I can see (I also checked the jenkins TTCN3 tests) we are ready to start a new osmocom CNI release.

When the release is done we may finally merge the last patch for the OsmoPCU TTCN3 testsuite. We also may then drop the support for the old PCUIF v10 everywhere (see last two checkboxes)

I have now removed the support for PCUIF v10 in osmo-pcu and also cleaned up the last remains of v10 support in osmo-bsc and osmo-bts

https://gerrit.osmocom.org/c/osmo-pcu/+/34706 pcuif_proto: drop support for PCUIF v10 [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/34707 pcuif_proto: clean up last remains of old PCUIF v10 [NEW]
https://gerrit.osmocom.org/c/osmo-bsc/+/34708 pcuif_proto: clean up last remains of old PCUIF v10 [NEW]

(We have discussed the problem with the missing PCUIF v10 support in the osmo-pcu TTCN3 tests and we came to the conclusion that it is better to use an older branch of the tests when we test older osmo-pcu branches. So this point is no longer on the list.)

The patches that remove the PCUIF v10 support from osmo-pcu are still in review, but I think we will soon be ready to merge them and close this ticket.