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
Update the state in the FSM before triggering paths implemented by the
user which may also again interact with the FSM. If the state is not
updated earlier, then the new interactions may encounter the FSM in an
unexpected state with regards to the event received.
Change-Id: I10eb23f6db5ff3b0b90f9066aa4fa44c8cb85170
New GMM-GMMREG-SIM_AUTH.ind/rsp primitives are added to allow GMM
resolving authentication request received from the network.
The user of the GMMREG SAP is responible for doing the resolution using
its SIM.
Depends: libosmocore.git Change-Id Id619459c17976b77cd2c7e4179123bb06807285c
Change-Id: I5c97642baac5ed29de63ae93fc7f0ecde5edf735
There's no use in keeping them in inactive state.
This allows upper layers recreating them upon next SMREG-PDP_ACT.req.
Change-Id: Ic9f9ae3becb0c26a55a3b08959a00a7df0bdb5b2