Feature #4547: support for frequency hopping in osmo-pcu - OsmoPCU - Open Source Mobile Communications

Actions

Copy link

Feature #4547

closed

support for frequency hopping in osmo-pcu

Added by laforge almost 4 years ago. Updated over 3 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

fixeria

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

Actions

Copy link

Updated by laforge almost 4 years 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

Actions

Copy link

Updated by fixeria almost 4 years ago

Status changed from New to In Progress

Actions

Copy link

Updated by fixeria over 3 years 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.

Actions

Copy link

Updated by fixeria over 3 years 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)?

Actions

Copy link

Updated by laforge over 3 years 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.

Actions

Copy link

Updated by fixeria over 3 years 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.

Actions

Copy link