Project

General

Profile

Actions

Feature #5927

closed

use "Direct TLLI" method to confirm IMMEDIATE ASSIGNMENT messages towards PCU

Added by dexter about 1 year ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
02/28/2023
Due date:
% Done:

100%

Spec Reference:

Description

To assign downlink TBFs, the PCU sends an IMMEDIATE ASSIGNMENT MAC block through the PCU SOCK interface to the BTS. The BTS confirms the sending of this IMMEDIATE ASSIGNMENT to the PCU by sending the MAC block back to the PCU. The MAC block essentially serves as a reference for the confirmation message. This method has some disadvantages so we decided to replace it.

The new method attaches a TLLI (and a paging group field) to the MAC block when it send to the BTS. The BTS then uses the TLLI instead of the MAC block as an identifier to confirm the sending of the IMMEDIATE ASSIGNMENT. The OsmoPCU already supports the method but OsmoBTS still have to be upgraded.

The related PCU/BTS TTCN3 tests also require an update.


Checklist

  • update TTCN3 tests for osmo-bts (stay compatible)
  • update osmo-bts
  • update TTCN3 tests for osmo-pcu to PCUIF v11
  • drop support for old PCUIF in osmo-pcu (final step)
  • get rid of unusued parameters in PCUIF_data_cnf_dt
  • rename tlli struct member to "msg_id"
  • add "confirm" struct member to struct gsm_pcu_if_pch_dt instead of parsing MAC blocks in osmo-bts/osmo-bsc
  • get rid of _DT/_dt and use _2/2 where it is required (same as with other APIs that get updated)
  • re-add compatibility for PCUIF v.10 to the TTCN3 tests of osmo PCU
Actions #1

Updated by fixeria about 1 year ago

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);
Actions #2

Updated by dexter 11 months ago

  • Checklist item update TTCN3 tests (stay compatible) added
  • Checklist item update osmo-bts added

For osmo-bts there is a WIP patch by fixeria in gerrit: https://gerrit.osmocom.org/c/osmo-bts/+/31600

Unfortunately we can not upgrade osmo-bts alone, we must upgrade it along with the TTCN3 tests in one go. Also in order to keep the -latest tests running we must take care that the TTCN3 tests also work with the previous version of osmo-bts

Actions #3

Updated by dexter 11 months ago

  • Checklist item changed from update TTCN3 tests (stay compatible) to update TTCN3 tests for osmo-bts (stay compatible)
  • Checklist item update TTCN3 tests for osmo-pcu (stay compatible) added
  • Checklist item drop support for old PCUIF in osmo-pcu (final step) added
Actions #4

Updated by dexter 11 months ago

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:

PCU->BTS PCU_IF_MSG_DATA_REQ with SAPI PCU_IF_SAPI_PCU_DT
  • no change: macblock
  • added: tlli, imsi
BTS->PCU PCU_IF_MSG_DATA_CNF_DT
  • no change: fn
  • added: tlli
  • removed: macblock
Actions #5

Updated by dexter 11 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

I have updated the PCUIF implementation in TTCN3 so that we have everything that is needed to support the direct TLLI method:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32604 PCUIF_Types: rename PCU_IF_SAPI_AGCH_DT to PCU_IF_SAPI_PCH_DT [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32605 PCUIF_Types: add message type PCU_IF_MSG_E1_CCU_IND [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32606 PCUIF_Types: add record PCUIF_pch_dt [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32607 PCUIF_Types: add templates for PCU_IF_MSG_DATA_CNF_DT message types [NEW]

Actions #6

Updated by dexter 11 months ago

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

Actions #7

Updated by dexter 11 months ago

  • % Done changed from 10 to 20

It appears that the receiving end should confirm not only IMMEDIATE ASSIGNMENT messages, but also PAGING COMMAND messages. Apart from that we should stick to one of the two PCH SAPIs (which is SAPI_PCU_IF_PCH_DT) only when deprecating the older PCUIF v.10.

The following two patches clean this up:
https://gerrit.osmocom.org/c/osmo-pcu/+/32694 gprs_rlcmac: also use direct TLLI PCUIF for paging macblocks
https://gerrit.osmocom.org/c/osmo-bsc/+/32693 pcu_sock: fix PCUIF interface (PCH)

There is also another patch for osmo-bts that cleans up paging.c to make clear that IMMEDIATE ASSIGNMENT and PAGING COMMAND macblocks are treated equally
https://gerrit.osmocom.org/c/osmo-bts/+/32687 paging: rename all IMM.ASS references to MACBLOCK

I have also started working on @fixeria's patchset https://gerrit.osmocom.org/c/osmo-bts/+/31600 - it already works but I still have to clean up it a bit.

Actions #8

Updated by dexter 10 months ago

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)

Actions #9

Updated by dexter 10 months ago

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)

Actions #10

Updated by dexter 10 months ago

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.

Actions #11

Updated by dexter 10 months ago

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

Actions #12

Updated by dexter 10 months ago

  • % Done changed from 20 to 30

I have BTS_Tests.TC_pcu_data_req_imm_ass_pch now running on PCUIF v.11. Since I have modified f_PCUIF_tx_imm_ass_pch, the other tests should be fine to. I still need to add some logic to switch between PCUIF v.11 and PCUIF v.10 to maintain compatibility.

I noticed that osmo-pcu and osmo-bsc use an incorrect SAPI. This only affects PCUIF v.11:
https://gerrit.osmocom.org/c/osmo-pcu/+/33339 pcu_l1_if: use correct SAPI in PCUIF message PCU_IF_MSG_DATA_CNF_DT
https://gerrit.osmocom.org/c/osmo-bsc/+/33340 pcu_sock: use correct SAPI in message PCUIF PCU_IF_MSG_DATA_CNF_DT

We might also consider to remove all the unused struct members in struct gsm_pcu_if_data_cnf_dt.

Actions #13

Updated by dexter 9 months ago

  • Checklist item update TTCN3 tests for osmo-bts (stay compatible) set to Done
Actions #14

Updated by dexter 9 months ago

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

Actions #15

Updated by dexter 9 months ago

  • % Done changed from 30 to 40

The following adds PCUIF v.11 support to OsmoBTS. There is no backward compatibility.
When this patch is merged all TTCN3 related patches must be merged as well:

https://gerrit.osmocom.org/c/osmo-bts/+/33522 pcu_sock: use PCUIF version 11 (direct TLLI)

We also must make sure that current master is tested with PCUIF v.11, while latest still must be
tested with the older PCUIF v.10. The following patch adds some logic to docker-plachround to
accomplish that:

https://gerrit.osmocom.org/c/docker-playground/+/33521 ttcn3-bts-test/jenkins.sh: set mp_pcuif_version

Actions #16

Updated by dexter 9 months ago

  • Checklist item update osmo-bts set to Done
Actions #17

Updated by dexter 9 months ago

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

Actions #18

Updated by dexter 9 months ago

  • % Done changed from 40 to 50

The Patch for osmo-bts is now also merged. As expected, the TTCN3 tests are now normal again.

We can now focus on updating the TTCN3 testsuite for osmo-pcu. This will be a lot easier since osmo-pcu (currently) has support for both PCUIF versions, so we do not have to worry about master and latest.

Actions #19

Updated by dexter 8 months ago

  • % Done changed from 50 to 60

I have started to port the PCU TTCN3 testsuite to PCUIF v.11:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33793 PCUIF_Types: add decoder for PCUIF_pch_dt
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33794 GPRS_Components: use more suitable SAPI for DL TBF assignment
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33795 PCUIF_Components: add compatibility for PCU_IF_SAPI_PCH_DT
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33796 PCU_Tests: use PCUIF v.11 exclusively

It works already for TC_pcuif_fh_imm_ass_dl, to make sure that the other tests work as well I need to try the patch set in docker first. Since there were patches that affect the PCUIF after release 1.2.0 the past patch (33796) will most likely break latest. We may wait till the next release or add logic that allows us to switch the PCUIF version (like we already have it for osmo-bts). The other patches should be safe.

Actions #20

Updated by dexter 8 months ago

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.

Actions #21

Updated by dexter 8 months ago

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.

Actions #22

Updated by dexter 8 months ago

  • Checklist item get rid of unusued parameters in PCUIF_data_cnf_dt added
  • Checklist item rename tlli struct member to "msg_id" added
  • Checklist item add "confirm" struct member to struct gsm_pcu_if_pch_dt instead of parsing MAC blocks in osmo-bts/osmo-bsc added

Originally I intended to shift those changes to the end but I think it is better to do the cleanup first and then rebase the AGCH confirmation patches on that state. As discussed with pespin I have renamed the tlli struct member to msg_id. This is due to the fact that it is just an implementation detail of osmo-pcu that the TLLI is used as an identifier here. For the other programs, osmo-bts and osmo-pcu, is just a number and has no relation to the TLLI at all. So msg_id is more appropriate here. I also removed the tail of unusued parameters in gsm_pcu_if_data_cnf_dt. So this part is also now less disctracting:

https://gerrit.osmocom.org/c/osmo-pcu/+/34100 pcuif_proto: rename tlli to msg_id
https://gerrit.osmocom.org/c/osmo-pcu/+/34101 bts: get rid of fn parameter in bts_rcv_imm_ass_cnf
https://gerrit.osmocom.org/c/osmo-pcu/+/34102 pcuif_proto: remove unnecessary members from gsm_pcu_if_data_cnf_dt

https://gerrit.osmocom.org/c/osmo-bts/+/34103 pcuif_proto: rename tlli to msg_id
https://gerrit.osmocom.org/c/osmo-bts/+/34104 pcu_sock: get rid of fn parameter in pcu_tx_pch_data_cnf
https://gerrit.osmocom.org/c/osmo-bts/+/34105 pcuif_proto: remove unnecessary members from gsm_pcu_if_data_cnf_dt

https://gerrit.osmocom.org/c/osmo-bsc/+/34106 pcuif_proto: rename tlli to msg_id
https://gerrit.osmocom.org/c/osmo-bsc/+/34107 pcuif_proto: remove unnecessary members from gsm_pcu_if_data_cnf_dt

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34108 PCUIF: rename tlli to msg_id
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34109 PCUIF_Codec port, do not return fn in f_PCUIF_tx_imm_ass_pch
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34110 PCUIF_Types: remove unnecessary members from record PCUIF_data_cnf_dt

Actions #23

Updated by pespin 8 months ago

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.

Actions #24

Updated by dexter 8 months ago

  • Checklist item get rid of _DT/_dt and use _2/2 where it is required (same as with other APIs that get updated) added

I originally wanted to drop the _DT later but I think doing it now is also a good choice. I have added the following patches now:

https://gerrit.osmocom.org/c/osmo-pcu/+/34134 pcuif_proto: get rid of _DT, _dt (Direct TLLI) [NEW]
https://gerrit.osmocom.org/c/osmo-bsc/+/34136 pcuif_proto: get rid of _DT, _dt (Direct TLLI) [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/34137 pcuif_proto: get rid of _DT, _dt (Direct TLLI) [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34138 PCUIF_Types: get rid of _DT, _dt (Direct TLLI) [NEW]

Actions #25

Updated by dexter 8 months ago

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.

Actions #26

Updated by dexter 7 months ago

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

Actions #27

Updated by dexter 7 months ago

  • Checklist item add "confirm" struct member to struct gsm_pcu_if_pch_dt instead of parsing MAC blocks in osmo-bts/osmo-bsc set to Done

As suggested, I have now added a confirmation flag to struct gsm_pcu_if_pch. Unfortunately we cannot decide at random if we want a confirmation or not. The reason for this is that in OsmoBSC we are limited by the propritary ericsson RBS RSL extensions. There it is simply not possible to get a confirmation for a PAGING (which is never needed). Technically we will require a conformation for all IMMEDIATE ASSIGNMENT messages that are sent through the PCH, while we do not require confirmation for PAGING messages, so the flag is more used to distinguish IMMEDIATE ASSIGNMENT messages from PAGING messages. That is the reason why I called the flag "confirmed_imm_ass" and not "confirm".

https://gerrit.osmocom.org/c/osmo-pcu/+/34190 pcuif_proto: add confirmation flag to struct gsm_pcu_if_pch [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/34191 pcuif_proto: use confirmation flag in struct gsm_pcu_if_pch [NEW]
https://gerrit.osmocom.org/c/osmo-bsc/+/34192 pcuif_proto: use confirmation flag in struct gsm_pcu_if_pch [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34194 PCUIF: use confirmation flag in struct gsm_pcu_if_pch [NEW]

Actions #28

Updated by pespin 7 months ago

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.

Actions #29

Updated by dexter 7 months ago

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.)

Actions #30

Updated by dexter 7 months ago

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]

Actions #31

Updated by dexter 7 months ago

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

Actions #32

Updated by dexter 7 months ago

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]

Actions #33

Updated by dexter 7 months ago

  • Checklist item changed from update TTCN3 tests for osmo-pcu (stay compatible) to update TTCN3 tests for osmo-pcu to PCUIF v11
  • % Done changed from 60 to 90

All relevant PCUIF patches are now merged. We now have reached the following improvements (compared between v10 to v11):

  • New SAPI PCU_IF_SAPI_PCH_2 replaces the old SAPI PCU_IF_SAPI_PCH
    • Data is encapsulated in a struct struct, so no manual concatenation of meta data (IMSI, msg_id etc.) needed.
    • Confirmation is no longer done by sending the whole MAC block back to confirm the sending of the MAC-Block (data_cnf). Instead we now have a dedicated member "msg_id" that carries a 32-bit identifier that is sent back to confirm the sending of the MAC block.
    • Confirm flag. The "confirm" flag allows the PCU to decide whether a confirmation should be sent back or not. It is no longer up to OsmoBTS or OsmoBSC to decide whether a confirmation is required.
    • IMSI member. When sending data through the PCH a paging group must be calculated. We now have a dedicated member for the IMSI
  • New SAPI PCU_IF_SAPI_AGCH_2 replaces the old SAPI PCU_IF_SAPI_AGCH
    • Same features as in SAPI PCU_IF_SAPI_PCH_2 but without the IMSI member.
  • New primitive data_cnf2 (struct gsm_pcu_if_data_cnf) added
    This primitive is now used to confirm the sending of MAC blocks towards the PCU. There are struct members for the msg_id and the sapi of the concerned message.

In current-master OsmoBSC we now only use SAPI PCU_IF_SAPI_PCH_2 and SAPI PCU_IF_SAPI_AGCH_2, the same is true for OsmoBTS. This means both now fully support the PCUIF v11 protocol. In OsmoPCU we also fully support PCUIF v11 but we still have compatibility for v10. We plan to drop the compatibility for v10 in OsmoPCU soon after the next release.

Actions #34

Updated by dexter 7 months ago

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)

Actions #35

Updated by dexter 7 months ago

  • Status changed from In Progress to Stalled
Actions #36

Updated by dexter 6 months ago

  • Checklist item update TTCN3 tests for osmo-pcu to PCUIF v11 set to Done
  • Status changed from Stalled to In Progress

The TTCN3 testsuites for osmo-pcu (latest and master) are now upgraded to use PCUIF v11. Unfortunately the update didn't go as smooth as we anticipated. We had some subtile problems in the testsuite that caused some fallout. This is now all fixed and at least for master the testsuite has recovered to what it was before. In latest I can see that there is still a small dip in the trend. I think we should have a look at this to make sure it is not PCUIF related.

Actions #37

Updated by dexter 6 months ago

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]

Actions #38

Updated by dexter 5 months ago

  • Checklist item re-add compatibility for PCUIF v.10 to the TTCN3 tests of osmo PCU added

In order to save extra work we have planned the migration from PCUIF v10 to v11 of the OsmoPCU TTCN3 so that we would get away without caring about backward compatibility to v10. This was offered itself since OsmoPCU offered support for v10 and v11. This means that we even after the release there was no stress upgrading the tests to v11 and when done, both latest and master would work with v11. Unfortunately it turned out that we still have to support older branches of OsmoPCU that only support PCUIF v10. This means we still meed support for v10 in the testsuite. I have checked back what it would take to add compatibility for v10.

I think it wouldn't be that hard to re-add PCUIF v10 support. One thing I noticed is that a lot of SAPIs are defined by having default values in the respective functions (PCUIF_components / GPRS_components). I would suggest to keep those defult values but add a check inside the function body. So for example when the default says PCU_IF_SAPI_PCH_2, and the function is called with SAPI PCU_IF_SAPI_PCH_2, then we would check if we use PCUIF v10 and then re-assign the SAPI to PCU_IF_SAPI_PCH automatically.

Actions #39

Updated by dexter 5 months ago

  • Checklist item re-add compatibility for PCUIF v.10 to the TTCN3 tests of osmo PCU set to Done
Actions #40

Updated by dexter 5 months ago

(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.

Actions #41

Updated by dexter 5 months ago

  • Checklist item drop support for old PCUIF in osmo-pcu (final step) set to Done
Actions #42

Updated by dexter 5 months ago

  • % Done changed from 90 to 100

The last three patches are merged now. This means we can finally conclude this ticket.

Actions #43

Updated by dexter 5 months ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)