| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When a PDCH is idle, then the gaps are filled with dummy blocks. OsmoPCU
supports generating the dummy blocks locally, so that a continous stream of
PDCH blocks is sent to L1. However, some BTS models (the OsmoTRX based models
in particular) are able to generate the idle blocks locally. In this case the
PCU should leave the genration of the dummy blocks to the BTS in order to
save processing time and load on the PCUIF interface.
In gprs_rlcmac_sched we already have a flag to skip idle frames in case we do
not use the so called "direct phy access". A similar mechanism also exists in
pcu_l1_if.cpp in function pcu_rx_rts_req_ptcch().
Unfortunately this check is not implemented correctly. The flag gets set when
the ENABLE_DIRECT_PHY define constant is set. However, this does not say
anything about whether the BTS model supports the generation of idle blocks or
not. The define constant is intended to be used to disable direct phy related
code in on platforms where no direct phy code is used or cannot be used. We
must instead check the BTS model (bts->bts_model) in order to decide whether
this particular BTS type requires the generation of dummy blocks or not.
Related: OS#6191
Change-Id: I7a08d8cc670fa14f7206ffffdbc22351f3668a17
(cherry picked from commit 469584f136061261bb7b05006d674aca42e3b150)
|
|
At the moment the PCU has no way of knowing with which BTS model it is
used with. However, some BTS models may require slightly different
behaviour by the PCU, depending on which BTS model is used. So, lets add
an additional bts_model field to struct gsm_pcu_if_info_ind in order to
convey the exact BTS model to the PCU and store this information in
struct gprs_rlcmac_bts
Related: OS#6191
Change-Id: I48eb75f65ab54fdec41ef913e24c1f18cd4a4047
(cherry picked from commit 26dca56db7302a31e1710d364abf515a8af250f2)
|
|
The vty command 'show bts pdch' had the UL and DL TBF count reversed.
This patch corrects that.
Change-Id: Ic906ca9d02811cb96e4530af43fbc3769f6afce7
(cherry picked from commit c25f4fb9c99357ea40bff907e1de7ddea77e0784)
|
|
This has been fixed in osmo-bts too.
If frames are not deliverd fast enough to the DSP, bursts will get
dropped. The osmo-bts-sysmo process must have priority over other
processes, so it can deliver frames fast enough.
Related: OS#6199
Change-Id: Ifa2c36bc0975e89d21b6fb2fc49db6077e5207da
(cherry picked from commit 952f5c7b9566aff2322fb226d23103bd503fa152)
|
|
Fix OsmoPCU not restarting if e.g. an external gsmtap IP is configured
that is currently not available. Also make the service files more
consistent with other Osmocom projects.
Revert f81e2f76 ("systemd: Do not re-start in case of exit(1) (e.g. a
config issue)").
Related: SYS#6581
Change-Id: I061206a6f61abddfa698a4ce809afcbdf0cbce9c
(cherry picked from commit 24a2ac99d4fcbea18ac90ad88c6116179c5a71c2)
|
|
We cannot see how uninitialized access is possible, but gcc v13.2.1
does complain about it. Let's work this around by assigning an
invalid value, like trx_count_free_tfi() does.
src/bts.cpp: In function 'int bts_tfi_find_free(const gprs_rlcmac_bts*,
gprs_rlcmac_tbf_direction,
uint8_t*, int8_t)':
warning: 'tmp_first_tfi' may be used uninitialized [-Wmaybe-uninitialized]
Change-Id: Ia446cdf573ee25e6da6b4aa917972c63472229bb
Fixes: OS#6190
(cherry picked from commit 30a7d26c83be79ac6d592bf3b6a96575f15362ba)
|
|
Change-Id: I7fe48ac3176f9d48660260fb268ee22eedc78d1a
|
|
That code path was incorrectly removed a few commits back, re-add it.
Fixes: 40a297f3b0c8e1670d46a4974750dd3335bc7885
Change-Id: I27e61dc4b3396360327dcd377d171daa30684d23
|
|
Change-Id: I1b6c967fd93fab1ff1751bf0c2802abdf0cd835a
|
|
When printing the PCUIF protocol version, we only mention OsmoBTS, but
since OsmoPCU can also be used in co-location with OsmoBSC, we should
also mention OsmoBSC here. Let's write "OsmoBTS/OsmoBSC"
Related: OS#5927
Change-Id: Ibe49064d04dff0617357e3e0b00fea961b657784
|
|
since OsmoPCU is no longer exclusively used in co-location to OsmoBTS
the module osmobts_sock (PCUIF) should get a more generic name.
Related: OS#5927
Change-Id: Ic7f6246265fa31be189e4aea36dfaa89bd0eeddd
|
|
When a downlink IMMEDIATE ASSIGNMENT message is sent through the PCH,
an IMSI is always required in order to be able to calculate the paging
group. However, when the downlink IMMEDIATE ASSIGNMENT has to be sent
before the MS has completed the GMM ATTACH REQUEST, the IMSI is still
unknown. In this case we may assume that the MS is still in non-DRX
mode, which means it listens on all CCCH blocks (PCH and AGCH).
This means we may send the IMMEDIATE ASSIGNMENT through the AGCH in this
situation. This will also have the advantage that the scheduling through
the AGCH will have less latency than the paging queue.
Unfortunately the SAPI PCU_IF_SAPI_AGCH only supports sending whole MAC
blocks, so it won't be possible to attach a TLLI that can be used for
confirmation. To fix this, let's add a new SAPI_PCUI_IF_AGCH_2, that
works similar as SAPI PCU_IF_SAPI_PCH_2 and use it to send the
IMMEDIATE ASSIGNMENT through the AGCH.
CAUTION: This patch breaks compatibility with current master osmo-bts
and osmo-bsc (see "Depends")
Related: OS#5927
Depends: osmo-bts.git I29858fa20ad8bd0aefe81a5c40ad77a2559a8c10
Change-Id: I9effdcec1da91a6e2e7a7c41f95d3300ad1bb292
|
|
At the moment we let OsmoBTS (or OsmoBSC) look into the MAC block we
send and in case it is an IMMEDIATE ASSIGNMENT message, a confirmation
would be sent back. Unfortunately, this method is not very practical,
lets add a flag to struct gsm_pcu_if_pch to tell the receiving end that
the MAC block (data) needs to be confirmed when it is sent.
Related: OS#5927
Change-Id: Ia202862aafc1f0cb6601574ef61eb9155de11f04
|
|
Until now, if timeslot resources where being allocated for an MS
whose msclass is not known, msclass=12 was being selected.
While it's true that msclass=12 is quite a usual one implemented by
phones (Rx=4, Rx=4, Sum=5), some MS implementations may not support such
modes.
As a result, if the PCU allocates a TBF for an MS which its msclass is
not known (eg. because it used 1-phase access aka no Pkt Res Req), then
a minimal msclass=1 should be assumed. Otherwise, it may assign more
multislots than the MS can handle, and will work incorrectly since an
amount of RLC/MAC blocks won't be sent/received properly.
With the existing code base, changing the default MSCLASS to 1 would,
however, create a worse user experiencie for the vast majority of devices
(which are msclass >= 12). The code should be improved to first use only
1 TS until the MS CLASS is known, and at that point reallocate resources
and re-assign them (eg. RECONFIGURE TBF rlc/mac ctrl blk).
So, for now, simply add a hidden VTY config to allow changing the
default assumed MS Class, so that operators wishing to support all
devices can eg. set it to 1.
Change-Id: If80fdd793db7dad029faa83dbf980ffc4959e2e5
|
|
Since we now no longer refer to TLLI when we mean "message ID" (msg_id),
we should also remove the "_DT" / "_dt" suffix from structs and define
constants and replace it with "_2" if required.
Change-Id: If641b507dcb6b176109c99dce7cff2a7561364b0
Related: OS#5927
|
|
The struct gsm_pcu_if_data_cnf_dt was added when the first experiments
mit Ericsson RBS base stations were made. It is essentially a copy of
gsm_pcu_if_data, where the mamber "data" was replaced with a member
"msg_id" (which was originally called "tlli"). Since we didn't know
back then which parameters we would still need at some later point we
kept all the other parameters. However, to this day we never used the
parameters below fn. Even fn was only used for logging purposes, but is
now also unused.
Let's remove all those unused members.
(Since all removed members are at the tail of the struct,
compatibility with other programs that use the PCUIF should not break.)
Change-Id: Id6109264e4144c2ab7b8410d4087705d857cd4c9
Related: OS#5927
|
|
The function bts_rcv_imm_ass_cnf, which processes the confirmation
message from osmo-bts or osmo-bsc has an fn (frame number) parameter.
This parameter not used for anything other than logging. The source of
this frame number parameter is the conformation message that comes from
osmo-pcu or osmo-bsc. In the case of osmo-bsc the frame number is always
0, since osmo-bsc uses RSL and can not know the exact frame numbers.
since we do not really need the frame number for the confirmation, lets
remove the fn parameter entirely.
Related: OS#5927
Change-Id: I35bc99eaec5d0287ae3916bc668f0babaddfd6ce
|
|
To confirm downlink IMMEDIATE ASSIGNMENT messages, we use the TLLI as an
identifier and the related struct member is also called "tlli".
Unfortunately this is misleading since the message identifier does not
necessarly have to be a TLLI. It is just an implementation detail that
osmo-pcu uses the TLLI as a message identifier.
To make that clear, lets rename the tlli member (and variable and
parameter names where it is passed on) to "msg_id".
(Since this change only renames variables and struct members it will not
break compatibility with other programs that use the PCUIF)
Related: OS#5927
Change-Id: I4a25039dfe329e68879bc68936e49c4b190625e6
|
|
Change-Id: I2cfa0486a3483140ce219b4645e0544e7923870a
|
|
Change-Id: I4f8e3d0dcb721d51838b50aba5b40d0551c8d0c5
|
|
Change-Id: I402a34c62d6714f054e8a3ff9042de3d2cf30727
|
|
is raised
This is a port of libosmo-gprs.git commit 49535bec37caddcea5718ed4e526c477c71f1b3a applied to osmo-pcu.
Problem this patch is fixing:
The current RLCMAC code is never invalidating the BSNs which have
been received after they are not needed.
This is somehow workaround by the following check when eg BSN wraps
around 127->0 and the BSN=0 is received:
""""
rcv_data_block_acknowledged()
m_window.m_v_n.is_received(rdbi->bsn)
/* Offset to the end of the received window */
offset_v_r = (m_v_r - 1 - bsn) & mod_sns();
return m_v_n.is_received(bsn) && offset_v_r < ws();
"""
The first m_v_n_is_received() would return true because the BSN has
never been invalidated, which is wrong, but fortunately the extra check
"offset_v_r < ws()" returns > ws() since:
v_r=0, bsn=0: "(0 - 1 - 0) & 127" ----> 0xffff & 0x007f ---> 0x007f > 64
So thanks to the above the BSN is considered not received, but looking
at the V(N) array would say the opposite. Hence, this commit aims at
fixing the V(N) array to contain proper values (marked "invalid") for
BSNs becoming out of the window when it rolls forward.
Explanation of the solution:
The V(N) array contains the status of the previous WS (64 in GPRS) data
blocks. This array is used to construct the RRB signaled to the peer
during PKT UL ACK/NACK messages together with the SSN (start sequence
number), which in our case is mainly V(R), aka one block higher than the
highest received block in the rx window.
Hence, whenever PKT UL ACK/NACK is transmitted, it contains an RRB
ranging [V(R)-1,...V(R)-WS)] mod SNS (SNS=128 in GPRS).
The receive window is basically [V(Q) <= BSN < V(R)] mod SNS, as is of
size 64.
The V(R) is increased whenever a highest new block arrives which is in the
receive window (guaranteeing it will be increased to at most V(Q)+64.
Since we are only announcing state of blocks from V(R)..V(R)-WS, and
blocks received which are before that BSN are dropped since don't fall
inside the rx window, we can securely mark as invalid those blocks
falling behind V(R)-WS whenever we increase V(R).
Related: OS#6102
Change-Id: I5ef4dcb0c5eac07a892114897f9e4f565b1dcc2c
|
|
This new structure was already used when porting existing osmo-pcu code
to libosmo-gprs-rlcmac, and proved to be much more clear.
It makes no sense to keep both ul and dl window code mixed, since the
code base is mostly different between them, and the developer usually is
only interested in reading/debugging one side at a time.
Change-Id: If21b6f48ef190a718502389cbfde8cbdfc8d7f7a
|
|
Otherwise unit tests (the only real used of that API so far) would end
up with v_r and v_q variables reset, but with previous state in v_n
array, which is not good.
Let's make sure everything is reset in
gprs_rlc_ul_window::reset_state(), and simply call that method during
constructor time.
Change-Id: I007b672527664b05353077b9208722056799f43f
|
|
in handle_retrans_pkt_cell_chg_notif, the variable neigh_key is used
uninitialized at end of the function. This has been introduced with
Change I96280f0ec5955ed3cb17641bf4118496c929bdac, where we modified
fill_neigh_key_from_bts_pkt_cell_chg()_not so that it write directly
at the ctx variable. This works in st_initial but not in
handle_retrans_pkt_cell_chg_notif(), so let's have neigh_key and
neigh_key_present as a parameter so that the caller can decide where
the result is stored.
Fixes: CID#322150
Related: OS#6100
Change-Id: I7e74beda03829d909b6542659316241c275a36b3
|
|
The NACC procedure in OsmoPCU currently only supports NACC with GERAN
cells. When an UTRAN or E-UTRAN cell is proposed in the
PacketCellChangeNotification, then the FSM is immediately terminated,
meaning that the NACC procedure can not commence.
When the NACC procedure is carried out for UTRAN or E-UTRAN cells, the
PCU will not send any system information to the UE. Instead it
immediately sends a PacketCellChangeContinue message. This also means
that we do not carry out any RAN Information Requests in the background.
This patch adds logic to detect if the proprosed cell is an UTRAN or
E-UTRAN cell and the adds a new transition to the FSM so that a short
route to NACC_ST_TX_CELL_CHG_CONTINUE can be taken.
Related: OS#6044
Change-Id: I96280f0ec5955ed3cb17641bf4118496c929bdac
|
|
Related: OS#6097
Change-Id: I327ca0e0f53be2d9b2a0705fe4de600229bdc5f9
|
|
These errors started appearing lately when upgrading builders to
debian12, with a newer gcc version.
Change-Id: I0046a6f4fb3979710b4cd5222de599d9aaac227b
|
|
A recent commit adding TBF_ST_WAIT_REUSE_TFI state updated
ms_append_llc_dl_data() to attempt creating a new DL TBF while in that
state, but forgot to update the assert checking for the conditions in
ms_is_reachable_for_dl_ass().
Related: OS#6084
Fixes: 40a297f3b0c8e1670d46a4974750dd3335bc7885
Change-Id: I3d51e909c9a9f688b7f4425a5ba319d183c71d1f
|
|
Change-Id: If37907b2f75b61b3243b9d8499bb0cf5c02c28c1
|
|
Change-Id: Ifdc46a228752452c8d403f2d49f4bac23c450b4d
|
|
The function neigh_cache_lookup_entry() is only used from within
neigh_cache.c. Let's make it static and move it, so that we do not need
the prototype declaration.
Change-Id: I1ea72ad9c79bfeaa06391cf8f62b284fbfea8efc
|
|
As seen during manual testing:
20230628140439674 DTBF tbf_dl.cpp:116 MS(IMSI-901700000015256:TLLI-0xd4d57c9d:TA-0:MSCLS-12-12) Allocating DL TBF
...
20230628140439674 DTBFDL tbf_dl.cpp:489 DL_TBF(DL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){NEW}: Received Event ASSIGN_ADD_CCCH
20230628140439674 DTBFDL bts.cpp:1108 TBF(DL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){ASSIGN} Tx CCCH (PCH) Immediate Assignment [PktDlAss=PDCH(bts=0,trx=0,ts=5)] TA=0
...
20230628140440238 DMS pdch.cpp:681 MS(IMSI-901700000015256:TLLI-0xd4d57c9d:TA-0:MSCLS-12-12:DL): + rcv_resource_request: now used by 2 (tbf,rcv_resource_request)
20230628140440238 DTBFDL pdch.cpp:738 TBF(DL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){ASSIGN} Got PACKET RESOURCE REQ while DL-TBF pending, killing it
20230628140440238 DTBF tbf.cpp:271 TBF(DL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){ASSIGN} free
...
20230628140440377 DTBFUL tbf_ul_fsm.c:169 UL_TBF(UL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){ASSIGN}: state_chg to FLOW
20230628140440377 DTBF tbf_dl.cpp:116 MS(IMSI-901700000015256:TLLI-0xd4d57c9d:TA-0:MSCLS-12-12:UL) Allocating DL TBF
20230628140440377 DTBFDL tbf_dl.cpp:475 DL_TBF(DL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){NEW}: Received Event ASSIGN_ADD_PACCH
20230628140440387 DTBF tbf_dl_ass_fsm.c:105 TBF(UL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){FLOW} start Packet Downlink Assignment (PACCH) for TBF(DL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){ASSIGN}
...
20230628140440816 DTBFDL bts.cpp:737 DL_TBF(DL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){FLOW}: Received Event ASSIGN_PCUIF_CNF
20230628140440816 DTBFDL bts.cpp:737 DL_TBF(DL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){FLOW}: Event ASSIGN_PCUIF_CNF not permitted
Change-Id: I042b0117552acae25c750e762f5cc254399da64f
|
|
Change-Id: I40f93473c86500f655a0a83c7816a065707e2ed9
|
|
Scenario: A DL TBF is assigned over PCH (CCCH) and we start transmitting
DL data blocks blindly after X2002, but at the same time the MS start
packet-access-procedure to request an UL TBF.
Right now osmo-pcu correctly detects the MS is available in PDCH and
re-assigns a DL TBF using PACCH, but the LLC frames it transmitted in
the old PCH-assigned DL TBF get lost when that older TBF is freed
(because the DL blocks were removed from the GprsMs llc_queue).
This issue is now more frequent since X2002 timer was added recently to
delay starting requesting USF for a UL TBF, hence the contention
resolution in general takes more time and hence the PACCH assignment of
the DL TBF takes more time too, so more DL data blocks are transmitted
to the DL TBF assigned over PCH during that time.
This patch improves the situation to at least recover the DL blocks
transmitted if the DL TBF is freed (due to MS merge trigger by scenario
mentioned above), where no DL ACK/NACK was ever received by the MS.
Ideal solution would be to have complete tracking of which LLC PDUs from
the llc_queues were completely ACKed at RLC/MAC level, but that really
requires a lot of work and major refactoring, which are left as a future
improvement.
Change-Id: I9be4035fb2cf2b3ee56e91dcc12cc8c24028b4aa
|
|
If in those states, we already left the FINISHED step which means we
already received a FinalACk previously, hence it means we are missing
requested retransmissions of the last DL ACK/NACK due to fn-advance
(several DL blocks in transit before receiving UL response).
Change-Id: Ib0f23a9cc3c614fe428b682e01502930cd2e478f
|
|
Due to the fn-advance feature, we schedule DL blocks in advance, which
may make several retransmitted DL ACK/NACK [RRBP] be in flight, and
hence several of them may be answered by the MS.
When the first one is received, we attempt to initiate a PktDlAss over
PACCH if new DL data was received meanwhile from SGSN.
However, if we receive duplicates of that final PKT CTRL ACK, we don't
want to re-initiate it again, since it is already ongoing.
Related: OS#5471
Change-Id: Idc204aba61ad98f75853dcd46200f5dcc4139203
|
|
In RELEASE state, the UL TBF is considered not available anymore, and we
are simply waiting in order to be able to reuse the allocated resources
(just in case it was still around). Hence, a UL TBF in that state should
not be selectable to initiate a DL TBF assignment over PACCH.
Related: OS#5472
Change-Id: Ia11f7802779cfeea15a71bddad9f7e0c6c1afb11
|
|
Otherwise the scheduler selects the UL TBF for USF during that time, and
of course no one has that USF assigned yet, so no answer and that ends
up triggering MAX_N3101 on the UL TBF.
This is specially important when PCU is connected to the BSC, since the
amount of time for the ImmAss to be scheduled on the BTS and reach the
MS can be bigger.
Change-Id: I48babd70ca44f11110240cbcfbab43d0e3a0fb59
|
|
Change-Id: I1da9b665b9ed83a644ea798008d456d6298b7460
|
|
A new state TBF_ST_WAIT_REUSE_TFI was added lately in dl_tbf_fsm, which
allows differentiating the time where the MS is listening on PACCH
after having sent last DL ACK/NACK, and time where it should already be
in idle mode.
In the former, the ms_need_dl_tbf() should return false since the MS is
still ongoing in packet-active mode (and new data incoming from SGSN
will trigger new DL TBF assignment over PACCH as needed), while in the
later we want to start a new PCH assignment.
Fixes: 40a297f3b0c8e1670d46a4974750dd3335bc7885
Change-Id: I96f311480d036859511c6ba825ccd36bdc71190b
|
|
T3192 on the MS side (boadcasted by the network on SI13) is used for the
MS to stay monitoring the PDCH of a DL TBF after sending PKT DL ACK/NACK
for the last DL data block (FinalAck=1).
T3193 is the counterpart in the network, defined as >T3192, which is
used to make sure the TFI is no longer used by the MS and hence can be
reused/re-assigned again.
Hence, we want to differentiate between those 2 timers, since the first
one gives us information on how late can we still tx PktDlAss on PACCH
on that DL TBF, while the later only provides info on when to free the
DL TBF in order to reuse the TFI.
Change-Id: I7421342461bf159d945651037e6fe690f88c6fae
|
|
In that code path, new_tbf is an UPLINK_TBF. Uplink TBFs (tbf_ul_fsm.c)
don't use state TBF_ST_WAIT_RELEASE, hence that condition cannot ever be
true.
Change-Id: I379d4140326a46e94914152fe9b735de852ceda0
|
|
Change-Id: Iba0d438f9ce20a5a4e293b0b36565f182824a136
|
|
When sending the last DL block, the FSM moves FLOW->FINISHED. Hence, it
is impossible to receive the FINAL_ACK in state flow, when we didn't yet
sent the last DL block (it's only possible if there's a bug in the MS).
TbfTest need to be adapted since they where acting wrong.
Change-Id: I3288743ff01ff84c3d345b6efb7c3fb6ca934791
|
|
Timer T3192 may be used in the future to know wheter a DL TBF assignment
can be sent on PACCH after the last DL TBF has finished (final ACK).
Change-Id: Ie5f6251ee773f56771f9a9507711a20e6282aac6
|
|
That timer is configured by value sent over PCUIF, hence better have it
to the same default value in osmo-bsc/osmo-bts.
Change-Id: I498f05ff4d232164690d177430e90eb99b4eea9d
|
|
Dispatching TBF_EV_CONTENTION_RESOLUTION_MS_SUCCESS means the UL TBF is
able to be used to assign DL TBFs over PACCH.
However, there's an extra implicit restriction: if the PCU already sent
the final UL ACK/NACK to that UL TBF, then whatever message sent
after it cannot be reliably answered, since the MS will go back to idle
state after issues the PKT CTRL ACK for that final UL ACK/NACK.
This condition is already being checked in
contention_resolution_success():
"""
if (ms_need_dl_tbf(ms()) && !tbf_ul_ack_waiting_cnf_final_ack(this))
ms_new_dl_tbf_assigned_on_pacch(ms(), this);
"""
Since we are considering the UL TBF to have done contention resolution
when we transmit the *first* UL ACK/NACK, it mans we are doing both things
on the same code path iif the *first* UL ACK/NACK is at the same time
the *final* UL ACK for that UL TBF. This can happen if the UL TBF is
only sending 1 block, which will have CV=0. This can usually happen
during GMM Attach Request.
In this scenario, with current code goes into a situation where first
the TBF_EV_CONTENTION_RESOLUTION_MS_SUCCESS is triggered and *afterwards*
the UL_ACK/NACK state is updated. As a result, the code snippet check
above (!tbf_ul_ack_waiting_cnf_final_ack()) will be true and the DL TBF
be assigned, but afterwards in the same code path it figures out the
final ack happens.
In order to fix this, first update the ACK/NACK state and only
afterwards trigger the Contention Resolution Success event.
Change-Id: I62ae91b494e4fd0ade3f4a3ba3817bcaedbdebf5
|
|
When we receive PCU_IF_MSG_DATA_CNF_DT, we check on PCU_IF_SAPI_PCH.
This is formally not correct, we should check on PCU_IF_SAPI_PCH_DT
instead.
(This patch will only affect osmo-bsc but not osmo-bts. The reason for
this is that osmo-bts still uses the older PCUIF v.10)
Depends: osmo-bsc.git Id5c799e625c56e57f7b51cd4fb57f5bea9c973d2
Change-Id: I0883b51fc232ec0267f1511c3a37c0bcd0967a08
|
|
Change-Id: I8c963ba7421faf2b3dcab006ea629c4628d17b44
|
