Age | Commit message (Collapse) | Author | Files | Lines |
|
This works around a problem that occurs if a mobile loses packet
data connectivity, e.g. moves out of coverage or switches over
to a circuit-switched call, while a data transfer is occurring.
The mobile would reset its LLC state, causing it to be
unsynchronized with the SGSN. Therefore the SGSN would drop
incoming frames until the sequence numbers matched. This
workaround resets the LLC state in the SGSN if T3350 expires,
indicating that Routing Area Updating Request, Attach Request,
or P-TMSI Realloc Command has failed.
|
|
According to TS 44.064 section 8.4.2, the LLC layer should only
drop UI frames if V(UR)-32 <= N(U) < V(UR). The code was dropping
frames whenever N(U) < V(UR). Consequently, large amounts of
packets could be dropped if, e.g., V(UR)==511 and the frame with
N(U)==511 was lost. All frames would be dropped until the next
time a frame with N(U)==511 is received.
|
|
TS 24.008 version 9.5.0 Release 9 sec 4.7.5:
In A/Gb mode, user data transmission in the MS shall be
suspended during the routing area updating procedure, except
if the routing area updating procedure is triggered by a PS
handover procedure as described in 3GPP TS 43.129 [113];
user data reception shall be possible. User data transmission
in the network may be suspended during the routing area
updating procedure.
|
|
|
|
The SGSN was updating the GMM state when sending the ATTACH_ACCEPT, when
it should enter that state after the ATTACH_COMPLETE is received.
|
|
already-attached MS
TS 24.008 version 9.5.0 Release 9 sec 4.7.3.1.6:
If an ATTACH REQUEST message is received in state GMM-REGISTERED
the network may initiate the GMM common procedures; if it turned
out that the ATTACH REQUEST message was send by an MS that has
already been attached, the GMM context, PDP contexts and MBMS
contexts, if any, are deleted and the new ATTACH REQUEST is
progressed.
|
|
|
|
|
|
|
|
Convert foreign TLLIs to local TLLIs for storage in LLME context.
|
|
than 4 octets
The SGSN was allowing MS Network Capability of up to 8 octets, but only allocating
storage for 4 octets.
TS 23.060 version 9.7.0 Release 9 section 6.14.2 states:
To allow for the addition of future features, the SGSN shall
store the UE Network Capability and the MS Network Capability
even if either or both is larger than specified in TS 24.008
[13]/TS 24.301 [102], up to a maximum size of 32 octets for
each IE.
|
|
than 14 octets
Newer phones are using a MS Radio Access Capability larger than the
14 octets specified in 04.08 Release 1998 (up to 50 octets in Rel 9).
This caused the SGSN to crash since it only allocated storage for
14 octets but tried to store up to 51 octets.
TS 23.060 version 9.7.0 Release 9 section 6.14.1.1 states:
To allow for the addition of future radio technologies, frequency
bands, and other enhancements, the SGSN shall store the MS radio
access capability even if it is larger than specified in TS 24.008
[13], up to a maximum size of 255 octets.
|
|
|
|
|
|
|
|
A bug in debian/control caused "debian/rules binary" to fail with:
dpkg-gencontrol: error: source package has two conflicting values - openbsc and opensgsn
|
|
This reverts commit eafe22ca7290280fca0f8d31d70239fd0b0dbb9d from upstream git
repository.
|
|
|
|
|
|
|
|
|