Age | Commit message (Collapse) | Author | Files | Lines |
|
The Starting time contains a "frame number, FN modulo 42432", aka RFN.
The translation to absolute FN was missing.
Depends: libosmocore.git Change-Id Ib71e8da976f6cc84c3a4ab17b0a8c2101492e243
Change-Id: I00741289333853a8db472950ee2ac38dc2c74fd3
|
|
Change-Id: I0572e9435330c15469f6609505867c21be9c3483
|
|
Change-Id: I8d31ed7cf89555a1ec3cbd91a77cc00cc42b546f
|
|
Change-Id: If0bbd9989413a550243a6496bce16b6eb04508db
|
|
Change-Id: I807e140b96de7140d8f6922417f3eaf0eadeed84
|
|
Change-Id: Ie52ced7e074a3d4451447551e1ac166397ee8a48
|
|
This is needed after RAU Update since the PCU may still be using the old
TLLI to reference the MS for a while until it finds out about the TLLI update.
Change-Id: I2653db3dac58342df02a1b4d0c76e69e0e8d583f
|
|
This enum should match osmo_gprs_gmm_gmmrr_prim_type, and I placed that
osmocom-specific enum at the wrong place in the rlcmac counterpart.
Change-Id: I3f198c756866417f8f975373f84fd3ec4da608fa
|
|
The "Radio Priority" received in GMM Attach Accept are for SMS and TOM8
SAPs only. For GMM/SM unitdata transferred to LLC, use highest
radio_prio=1.
Change-Id: Ie583c433547fb5ecbb6b6077c39a157961f73cfc
|
|
Closes: Coverity CID#322365
Change-Id: Icc65af3ea9a44a5daf80e47717564f6adf37444b
|
|
originating cause
Change-Id: I930a1fcf23506f75562a6795f9a6e42b187d2974
|
|
This simplifies the array handling in the LLC queue, and moves param
checking to the rx rlcmac_prim path instead of deep in the llc_queue
enqueuing code.
This commit also fixes the RADIO_PRIORITY field in the Channel Request
Description section of PKT DL ACK/NCK, since
gprs_rlcmac_llc_queue_highest_radio_prio_pending() now returns the enum
normalized 0..3 as expected by the field format (before it was returning
1..4).
Change-Id: If2d1946522bc4a1c19d65acb23605f1a3f05ab45
|
|
Change-Id: I70e355ef27d24bdaf00e54f0e7126193f5bbf19f
|
|
Ported from open5gs.git/lib/gtp/v1/types.{c,h} 5764f7267d16a8ea6aeedc6c227552575915def5,
for which I was the author too.
The ARP extra byte field at the start of the IE val which is introduced in the
GTP variant is dropped when porting to SM, since it's not present there
(and offsets/sizes are adjusted).
The QoS code is moved is moved into a common/ directory where a new
libosmo-gprs-common.la private static library is created.
This is done in order to be able to resuse the QoS dec/enc code in
several libraries since it's actually planned to use it in SNDCP and SM
layers.
The most natural place to add the APIs is SM, and that's where the
public API to accees the enc/dec is provided, since the user app will
have to use them in the SM SAP.
However, the SNDCP will also have to decode the QoS recived by SM
through the SNSM SAP, and we don't really want libosmo-gprs-sndcp depend
on libosmo-gprs-sm. This way libosmo-gprs-sndcp will be able to use the
private APIs directly in a follow-up commit.
Change-Id: I6c0676e55bb1f0f424f41d8d04d4f5e5bf376f4f
|
|
Change-Id: I2ace165003469c2a43d7333634171896699d5a5d
|
|
Change-Id: I632329bb1f34efb4d9263241e2cda5b559f1ff59
|
|
Change-Id: Ia8226f6e687f86b2502b27f9979dce13cf751c01
|
|
Change-Id: I8828e0019f6446c3a17d09e8483573bf752c159f
|
|
LLC is only expected to signal new values if SNDCP XID params are
received, or if the default N201 values change.
Change-Id: I68f54d329b326895ed8f010cf50f20fa30948d30
|
|
Change-Id: I962e25789849f89c532f5ede386fa029600d9901
|
|
Change-Id: I7429701ae49c2a694dcad3e3d5ec639ab9927f5b
|
|
Change-Id: I8135c5cef4df69a7c3a540050da0837bf2059df2
|
|
Change-Id: I2f2cb8b831266b8e4251c2832e6545bef776658c
|
|
Change-Id: I8c6b07305c0bcecb4e1681967884a3e62c813592
|
|
Take the chance to fix wrong indentation on related function parameter.
Change-Id: I8c0163583efc2720a4b2675ce93293c184f80d0c
|
|
Getting out of contention resolution means we may have to update our
calculated CV state because we are no longer sending TLLI.
Same happens if a new tx CS is provided by the network, since different
block size means different CV.
In this commit only code paths for the state where already in Countdown
Procedure are added. If TBF has to enter Countdown Procedure due the
above mentioned changes, it will do so using regular path where a new
RLC block is created.
Related specs: TS 44.060 9.3.1
Related: OS#6018
Change-Id: I6ca88c005060ba1302d46717e45b0d9731d86d8d
|
|
Recalculating CV when in Countdown Procedure will be implemented in a
follow-up commit.
Related: OS#6108
Change-Id: I1e7b28c2e5f1d77a962ec3070f3a027b8f66a69e
|
|
Discarding a packet through CoDel during Countdown procedure may end up
in the transmitted CV=14..0 being incorrect, since we are not really yet
recalculating them once we enter Countdown procedure.
Hence, to make it simpler for now, avoid dropping packets when in
Countdown procedure to avoid having to recalculate them.
Change-Id: I311302b5282767dc806b1dfe053994f175390b69
|
|
This clarifies the logic behind selecting the proper queue, and it will
be used further in the future, for instance when recalculating CV once
already in Countdown procedure.
Change-Id: Icceaf53048e9662176385b2976e2bc8e3387df71
|
|
This allows gathering more information on the state of the queue and
helps in understanding possible bugs on the CV calculation algo.
Related: OS#6108
Change-Id: I97f4977944a6f82abc7b39c4e578de9d8e152740
|
|
Problem this patch is fixing:
The current RLCMAC window code ported from osmo-pcu is never
invalidating the BSNs which have been received after they are not
needed.
As a result, when the DL TBF keeps sending data for a long time, and
finally BSN wraps around 127->0, when this implementation receives the
BSN=0, it will find it is already received and hence will discard it,
and then keep asking for BSN=0 nevertheless in PKT DL ACK, causing an
endless loop where PCU stays submitting the same block forever.
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 DL 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 DL 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: I962111995e741a7e9c230b2dd4904c2fa9a828e9
|
|
We want to do mod sns on the BSN, not on the boolean returned by
gprs_rlcmac_rlc_v_n_is_received().
This is a typo which occurred while porting the code from osmo-pcu.git
void gprs_rlc_ul_window::update_rbb(char *rbb), where the following line
is used:
"""
if (m_v_n.is_received((ssn()-1-i) & mod_sns()))
"""
Change-Id: I37c8fd5c2528f035f077c3e05105f913922ffd84
|
|
Change-Id: Ia8cd3ea341308887953fe76df6821c429b3d8e77
|
|
Change-Id: I7f90981a114070ff13c508f0c6800cc1dd2cfe14
|
|
Caught by ASan during test run. This can happen if
gprs_rlcmac_ul_tbf_schedule_next_llc_frame() finds no more llc frames to
submit during the loop iteration.
Change-Id: I5bd6dd6c6b7dc4b911af7bc119cf85eb810959a0
|
|
Change-Id: I63d68e524629a90931497d1181f134830b4819f9
|
|
Change-Id: I924dcf3ac9cbb15e26a5e9376f89ca098ab49e0b
|
|
TS 24.007, TS 24.008, TS 44.064 nor TS 44.065 explain how the TLLI
update happening during GMM RAU propagates to the SNDCP layer.
GMM only has interfaces towards LLC and GRR, and uses LLGMM-Assign.Req
and GMMRR-Assign.req to update the TLLI in the respective layers.
This patch adds a new primitive in the LL interface (LLC->SNDCP)
LL-Assign.ind to propagate the LLGM-Assign.req received from
GMM towards SNDCP, so that it can use the new TLLI in order to address
the specific MS.
Change-Id: Icb858f5397414b6d4183c21f13d35c0166ca7635
|
|
Change-Id: I8ddebf93d3150cc952f9e5fc5d6f3cfc99e912a5
|
|
Change-Id: Ic765b7a565cac4abcf34d8c6868e103971d17822
|
|
TS 24.007 and TS 24.008 seem to lack providing an explicit way to pass
information between GMM and SM (GMMSM interface) when a RAU process
happens in GMM (rx RAU Accept).
This lack of primitive can easily be spotted by looking at TS 24.007
Appending C.15, or even better, at the 3rd page of "C.16(cont’d)" around
the "STOP Trams" timer, where the info is magically available in SM when
being received at GMM.
Change-Id: I81e207d44d88f18f0ee13fb413827606a6f830bc
|
|
Change-Id: I8b4c5a6c4c4da3648160aa32f7586c74942c7734
|
|
The TLLI was wrong (I tooked the one from the Attach Accept msg instead
of RAU accept message defined above).
Change-Id: I2f7d61c72febad24fde285578e20485a23b8e175
|
|
Those IEs are aimed at upper layers (SM, SNDCP) and will be relayed in
follow-up patches.
Change-Id: I3a43b5e0417796f7dce4010cd6a6d3fd2d9c543e
|
|
This can be used for users receiving the GMMRR_ASSIGN_REQ primitive to
find out if it's a creation, update or deletion of a TLLI.
Change-Id: I881b1370b283ceee98c035ed42b91f7e12611979
|
|
This is used by lower layer L1CTL to notify the upper layer RLCMAC when
it's prepared to use CCCH.
Change-Id: I4cfb1e2db217a97b7a1dc8849cd13d58e4034c56
|
|
Change-Id: I9c32def9571294abe2e67235a50809839ed5966a
|
|
Change-Id: Id4b52b6110fc8012d5d3b4d341b9702e3142c334
|
|
Change-Id: I7d01c833b6b746d74e6ecd8c65c929a320a95d17
|
|
This even is triggered by the GSM itself due to internal timeouts as a
consequence of lower layers not resolving the request (with accept or
reject events).
Change-Id: Ic1072629595e75c411b421e71f6ffac5dd41da3b
|