It has been found that the negotiation of SNDCP compression entities with unknown algorithm type described in TS 44.065, subclause 6.8
was interpreted differently up to and including version 6.2.0 of the TS.
According to TS 44.065, subclauses 6.8.1
and 6.8.2, an SNDCP entity can accept a compression entity proposed by its peer SNDCP entity by not including it in the responding SNDCP XID block.
On the other hand, according to TS 44.065, subclause 6.8.3
, exception handling:
"In this subclause, the term "parameter" may refer, wherever applicable, to an SNDCP XID parameter, a compression field (for parameter type 1 or 2), or a parameter for a compression field. If the originating SNDCP XID block includes a parameter with unrecognised Type field, the parameter shall be ignored by the responder."
Some manufacturers have interpreted the above requirement in such a way that it applies also to the parameter "algorithm type" in the SNDCP XID parameters "protocol control information compression" and "data compression".
With such an interpretation, in some scenarios the SNDCP entity originating the XID negotiation cannot decide whether the peer SNDCP entity did not respond to a proposed compression entity in order to accept it or because it did not know the algorithm and therefore ignored the proposed compression entity.
In particular, some R97/98 MS implementations ignore a proposal for a protocol control information compression with algorithm type RFC2507, because this algorithm was only introduced in R99. Since the MS does not explicitly reject the proposed compression entity for RFC 2507, a R99 SGSN following TS 44.065, subclauses 6.8.1
and 6.8.2 may assume that the MS has accepted the proposal and will start using this compression entity. The MS will then discard the downlink packets compressed by the SGSN with RFC 2507.
TSG-CN #25 approved the CR 015r2 to TS 44.065
for Rel-4 and CR 016r2 from Rel-5 onwards. These CRs mandate explicit rejection of non-supported compression algorithms to remove the ambiguity.
All new GPRS mobile stations shall support the explicit rejection of non-supported compression algorithms as described above within four months of the relevant specification being approved by 3GPP.
For the algorithm RFC 2507 which was introduced in R99, the SNDCP entity in the network originating the XID negotiation can resolve this ambiguity by evaluating the revision level of its peer entity (revision level in the MS network capability IE), since a R99 implementation cannot treat RFC 2507 as unknown compression algorithm. To this purpose the SNDCP entity in the network needs to be informed about the revision level of the mobile station.
If the mobile station uses SNDCP version 0 and does not explicitly reply to the proposal for a compression entity, and the revision level of the mobile station is
- 'GSM phase 2':
the SGSN may assume that the entity was rejected, if the proposed algorithm was introduced in R99 or later. If the algorithm was introduced before R99, the network shall proceed as specified in TS 44.065;
- 'R99 or later':
the SGSN may assume that the entity was rejected, if the proposed algorithm was introduced in Rel-4 or later. If the algorithm was introduced in R99 or earlier, the network shall proceed as specified in TS 44.065.