Project

General

Profile

Feature #4547

support for frequency hopping in osmo-pcu

Added by laforge 5 months ago. Updated 29 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
05/13/2020
Due date:
% Done:

100%

Spec Reference:

Description

I just realized that OsmoPCU would also require related changes/enhancements. Contrary to the circuit switched domain, we never used frequency hopping at all for the PS domain, no matter which base station hardware.

At the very least, we would need to be able to
  • pass the hopping parameters (MAIO, HSN, ...) over the PCU socket so the PCU knows about them
  • encode the hopping parameters in any kind of RLC/MAC messages, specifically
    • Encoding::write_immediate_assignment()
    • Encoding::write_packet_uplink_assignment()
    • Encoding::write_packet_downlink_assignment()

There are possibly more required modifications, the above is not meant as an exhaustive list.


Related issues

Follows OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxResolved05/12/2020

History

#1 Updated by laforge 5 months ago

  • Due date set to 05/13/2020
  • Start date changed from 05/12/2020 to 05/13/2020
  • Follows Feature #4546: baseband frequency hopping support for osmo-bts-trx added

#2 Updated by fixeria 3 months ago

  • Status changed from New to In Progress

#3 Updated by fixeria 3 months ago

  • Due date deleted (05/13/2020)
  • % Done changed from 0 to 40

TTCN-3 test cases and the actual protocol extension (in PCUIF_Types.ttcn) have been submitted to Gerrit:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19322 library/PCUIF_Types: make PCUIF version configurable
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19323 library/PCUIF_Types: version 10: add frequency hopping parameters
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19324 PCU_Tests: verify handling of frequency hopping parameters

Misc changes:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19321 library/GSM_RR_Types: also match MobileAllocation in tr_IMM_TBF_ASS()
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19325 library/GSM_RR_Types: fix bit/byte order in MobileAllocation
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19333 library/Osmocom_Types: add f_rnd_bitstring() and f_pad_bit()

While working on this, I found and fixed a bug in Wireshark:

https://code.wireshark.org/review/37912 GSM RR: properly handle CSN.1 Null breakpoints in IA Rest Octets

What's covered by test cases so far is both Uplink and Downlink allocation through the AGCH/PCH - Immediate Assignment.

#4 Updated by fixeria 3 months ago

Unfortunately, the more fields we add, the larger every message gets. This is a flow in the original design of the PCUIF protocol. Currently (with the hopping params) the largest message is the INFO.ind - 704 bytes, so basically every message on the PCUIF gets aligned to 704 bytes, even if we need to send only 4-6 octets. Maybe we should rework the protocol at some point, so the messages would be less bloated (e.g. like L1CTL)?

#5 Updated by laforge 3 months ago

On Mon, Jul 20, 2020 at 01:53:56PM +0000, fixeria [REDMINE] wrote:

Unfortunately, the more fields we add, the larger every message gets. This is a flow in the original design of the PCUIF protocol. Currently (with the hopping params) the largest message is the INFO.ind - 704 bytes, so basically every message on the PCUIF gets aligned to 704 bytes, even if we need to send only 4-6 octets. Maybe we should rework the protocol at some point, so the messages would be less bloated (e.g. like L1CTL)?

why does it matter? Do you think there will be any performance difference? I would expect
the system call / scheduling overhead between two processes is much more expensive an
whether you have a 70 byte or 700 byte message makes very little difference, if any.

#6 Updated by fixeria 3 months ago

does it matter? Do you think there will be any performance difference?

Well, it's not really critical. Just strikes the eye when I see encoding results in TITAN. Regarding performance, I was thinking about a use case when osmo-pcu runs on a remote host. But then realized that PCUIF works over a UNIX socket, and we don't convert any fields to the network byte order... So yeah.

#7 Updated by fixeria 3 months ago

While working on this task, I faced Packet Downlink Assignment decoding failures. Should be fixed by:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19362 library/RLCMAC_CSN1_Types: fix definition of ZeroOneGamma
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19363 library/RLCMAC_CSN1_Types: fix definition of COMPACTreducedMA
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19364 library/RLCMAC_CSN1_Types: fix definition of PacketDlAssignment

#8 Updated by fixeria 3 months ago

  • % Done changed from 40 to 80

I have submitted a set of changes adding the test case coverage:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19323 library/PCUIF_Types: version 10: add frequency hopping parameters
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19324 PCU_Tests: verify handling of frequency hopping parameters

and even more fixes for our CSN.1 message definitions:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19342 library/RLCMAC_CSN1_Types: fix byte/bit order in GprsMobileAllication
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19369 library/RLCMAC_CSN1_Types: fix length field in GprsMobileAllication
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19370 fixup library/GSM_RR_Types: fix BYTEORDER in MobileAllocation

#9 Updated by fixeria 3 months ago

The test cases cover all messages (at least that I am aware of) that may contain hopping parameters:

  • TC_pcuif_fh_imm_ass_ul_egprs - (RR) Immediate (UL EGPRS TBF) Assignment,
  • TC_pcuif_fh_imm_ass_ul - (RR) Immediate (UL TBF) Assignment,
  • TC_pcuif_fh_imm_ass_dl - (RR) Immediate (DL TBF) Assignment,
  • TC_pcuif_fh_pkt_ass_ul - Packet Uplink Assignment,
  • TC_pcuif_fh_pkt_ass_dl - Packet Downlink Assignment.

I have a draft implementation for osmo-pcu, and it already passes the first three test cases.

#10 Updated by fixeria about 2 months ago

  • Status changed from In Progress to Feedback
  • % Done changed from 80 to 100

I just submitted the actual implementation:

https://gerrit.osmocom.org/c/osmo-pcu/+/19786 encoding: pass pdch slot directly to encoding functions
https://gerrit.osmocom.org/c/osmo-pcu/+/19787 encoding: use CSN.1 codec to generate Packet Uplink Assignment
https://gerrit.osmocom.org/c/osmo-pcu/+/19788 encoding: implement handing of hopping parameters
https://gerrit.osmocom.org/c/osmo-pcu/+/19789 pcuif_proto: version 10: add frequency hopping parameters

together with multiple cosmetic changes. All test cases pass with there changes applied.

#11 Updated by fixeria 29 days ago

  • Status changed from Feedback to Resolved

All changes have finally been merged.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)