The Countdown procedure (decreasing CV field in UL RLCMAC data blocks)
is defined in TS 44.060 9.3.1.
It is implemented by means of counting/calculating the amount of RLC/MAC
blocks to be transmitted based on the LLC frames in the several LLC
queues, without actually generating the RLC/MAC blocks. The blocks
cannot be generated ahead of time because that wouldn't allow recreating
them in case Tx UL CS changes, or if a higher priority LLC frames
arrives.
The functions calculating the required amount of RLC/MAC blocks are
coded so that they early return to avoid spending more time than
necessary counting blocks (< BS_CV_MAX).
An extra heuristic optimization to be used when LLC queues are long is left
documented as a TODO, in order to test further the general non-optimized
path for now. Once the counting is proved to work reliably, that and
other heuristic optimizations ca be implemented, like keeping and
decreasing CV cached counter while no Tx CS change occurs or no new LLC
frames are enqueued.
Change-Id: If043c86a0c2b89d0ac0b8174de39fbcb22bed8cb
Dummy LLC commands only make sense in the network->MS direction, in
order to delay closing the DL TBF (3GPP TS 44.064 6.4.2.2). That code in
the MS is a leftover from porting code from osmo-pcu.
Change-Id: I062aa9aea4f7d66a70ed53eae1c67780ddc3dca5
Basic implementation of gprs_gmm_decode_network_name() was cherry-picked
from osmocom-bb 2dfa84e73dca455900e6522f61f5c610077783b7
decode_network_name().
Change-Id: I9b81f8f9113a95cc75666dac5ff9e315d0845fcb
This information will be needed once the GRR layer starts listening for
paging requests, which identify MS by either PTMSI or IMSI.
Change-Id: I3a0c4a57c3d624c3ebb40ae2cc0c96626ccc2c99
enc/dec implementation and unit test are imported from osmo-sgsn.git
b83aabaa95695c61a64e5e990944f8e55934a976.
Change-Id: Ia3b903e8bc7890489390dcc5b2d4b60efd55dc2c
This event doesn't show up as an explicit primitive in TS 24.007 GMMRR
SAP, but it is clearly needed to (re)arm the READY timer in GMM layer as
per TS 24.008 section 4.7.2.1.1:
"""
The READY timer is started:
- in the MS when the GMM entity receives an indication from lower layers that an LLC frame other than LLC
NULL frame has been transmitted on the radio interface;
"""
Change-Id: I9fd4047cfae4a12ad3be41860032eeda263d3276
3GPP TS 44.064 loosely defines "QoS params" on each primitive by listing
the fields, which are a bit different on each primitive.
Change-Id: I6760bace69d400edd4576ec2820e29b74f8dfca5
App and SM itself may need access to PTMSI or TLLI.
PTMSI:
- App may want to store it somewhere in order to reuse it next time
it wants to GMM Attach.
TLLI:
- App will need the TLLI to identify the MS when sending/receiving
primitives over SN SAP (app<->SNDCP).
- SM layer will need the TLLI to communicate over SNSM SAP (SM<->SNDCP),
as well as relay the information to the app if the GMM Attach happens
implicitly over SMREG-Act_Pdp_Ctx.req -> GMMSM-Establish-Req.
Change-Id: I7b1b8ac414474652b438f15b7f07961032a0f56d
Upper layers (SM or app) may need access to PTMSI or TLLI.
PTMSI:
- App may want to store it somewhere in order to reuse it next time
it wants to GMM Attach.
TLLI:
- App will need the TLLI to identify the MS when sending/receiving
primitives over SN SAP (app<->SNDCP).
- SM layer will need the TLLI to communicate over SNSM SAP (SM<->SNDCP),
as well as relay the information to the app if the GMM Attach happens
implicitly over SMREG-Act_Pdp_Ctx.req -> GMMSM-Establish-Req.
Change-Id: I552c43c55409773e2d13b72cba45a866165f203f
Newer gcc errors about "cause" being uninitialized, but cause is
guaranteed to be set in the "case GPRS_GMM_MS_EV_LOW_LVL_FAIL" path, it
just fails to find out.
Since the approach used previously is a bit hacky, let's simplify it.
Change-Id: I1c96b0aa92d4f9205a1d4d1760c787fe0e0ed169
At that point in time we may still need it, for instance to send the
primitive to the upper layers. Still, we want it to be t the correct
state when that happens. Hence, delay freeing the object to happen in
next loop iteration, so that it is still available to submit the
primitive, and even skip freeing the object if the SM SAP user decides
to re-activate the PDP context in a synchronous code path from the
primitive callback.
Change-Id: I28655fc6286c92403e3e461cb6433b8567e20fd1
The GMM layer doesn't really have to differentiate between SM
connections, everything is sent over the LLC "GMM" SAPI.
However, we still want to identify/related a given MS if there are
multiple MS using the stack.
Change-Id: Ib757f016824d918ce8b74ae0c2a652a6c1823556