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