This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
neels gerrit-no-reply at lists.osmocom.orgHello Jenkins Builder, laforge, pespin, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-bsc/+/24369 to look at the new patch set (#10). Change subject: allow explixit TSC Set and TSC on chan activ / modif / assignment ...................................................................... allow explixit TSC Set and TSC on chan activ / modif / assignment Activating / modifying to a VAMOS mode will require picking specific TSC Set / TSC. It is a bad idea to pick the TSC in each message encoding function, rather make this choice centrally. So far we pick the training sequence code to use based on the timeslot configuration, and this TSC is determined only upon encoding the RSL messages. Instead, pick the TSC to use upon the initial lchan activation / modification request; store this in the request structs and pass through the activation / modification code paths. For VAMOS modes, we also need to pick a TSC Set. Do so also upon activ / modif request. Note that the TSC Set is not yet applied in this patch, it will be applied in upcoming VAMOS patches. The activ / modif request may pass -1 for tsc_set and/or tsc to indicate no specific choice of TSC Set and TSC, resulting in the same behavior as before this patch. For example, lchan->activate.info.tsc* may be passed as -1. The exact choice for tsc_set and tsc is then stored in lchan->activate.tsc*, i.e. one level up (the .info sub-struct is considered as immutable input args). The lchan->activate.tsc* are the values actually encoded in RSL messages. After the ACK, the lchan->activate.tsc* is stored in lchan->tsc* to indicate the TSC actually in use. Same for modif. Note that in 3GPP TS 45.002, the TSC Set are numbered 1 to 4, while the TSC are numbered 0 to 7. On the wire, though, TSC Set is sent as 0 to 3 value. This is a weird discrepancy, odd choice made by the spec authors. For conformance with the spec wording, I decided to pass the TSC Set number as a 1-4 ranged value, and only convert it to the 0-3 on-the-wire format upon message encoding. So log messages and VTY output will indicate the first TSC Set as "1", but the first TSC as "0", as defined in 3GPP TS 45.002, even if that is somewhat weird. Related: SYS#5315 OS#4940 Change-Id: Ic665125255d7354f5499d10dda1dd866ab243d24 --- M include/osmocom/bsc/assignment_fsm.h M include/osmocom/bsc/gsm_data.h M src/osmo-bsc/abis_rsl.c M src/osmo-bsc/assignment_fsm.c M src/osmo-bsc/bsc_vty.c M src/osmo-bsc/gsm_04_08_rr.c M src/osmo-bsc/lchan_fsm.c M src/osmo-bsc/lcs_loc_req.c 8 files changed, 81 insertions(+), 14 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-bsc refs/changes/69/24369/10 -- To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/24369 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bsc Gerrit-Branch: master Gerrit-Change-Id: Ic665125255d7354f5499d10dda1dd866ab243d24 Gerrit-Change-Number: 24369 Gerrit-PatchSet: 10 Gerrit-Owner: neels <nhofmeyr at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge at osmocom.org> Gerrit-Reviewer: pespin <pespin at sysmocom.de> Gerrit-MessageType: newpatchset -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210531/9c6cb982/attachment.htm>