It has been found that in some instances the one phase contention resolution procedure leads to interoperability issues.

To avoid interoperability issues, TSG GERAN#3 agreed on the following mobile station behaviour during the contention resolution phase (CR 04.60-A952):

1. A mobile station shall accept a Packet Uplink Assignment addressing it by the uplink TFI or TLLI; the mobile station shall act on this message according to the procedures defined in packet transfer mode during operation on an uplink TBF. If a valid RRBP field is received as part of this message, the mobile station shall transmit a Packet Control Acknowledgment in the block specified in uplink.
2. A mobile station may act on the other non-distribution messages addressing the mobile station with the TFI or TLLI, and may transmit a Packet Control Acknowledgment when a valid RRBP field is received in downlink RLC/MAC control blocks
3. A mobile station shall not answer to a polling request received in a Packet Uplink Ack/Nack message in case it includes a TLLI addressing another mobile station; then an ambiguous word is deleted in 3GPP TS 04.60 sub-clause 10.4.5.
4. To prevent a mobile station receiving downlink data intended to another mobile station, it is required that a mobile station in contention resolution phase shall not accept a PACKET DOWNLINK ASSIGNMENT nor a PACKET TIMESLOT RECONFIGURE message, whatever the address used in these assignment messages.

All new GPRS mobiles shall support the basic contention resolution procedure (covered by points 1, 2, and 3) as soon as the relevant specification (GSM 04.60 v6.12.0) is published by 3GPP. All new GPRS mobiles shall support the complete contention resolution procedure (covered by points 1, 2, 3, and 4) within four months of the relevant specification (GSM 04.60 v6.12.0) being published by 3GPP.

In order to force the rejection of occasional LLC frames that may be received by the wrong mobile station, ciphering needs to be applied. This will cause an LLC frame that is received by the wrong mobile station to be rejected by the receiving LLC entity.

It has been found that where two operators have a CS roaming agreement but no GPRS roaming agreement the GPRS specifications cause the user's SIM to be "invalidated for GPRS service". This means, for example, that a user roaming from his home network into a visited network and back to his home network will see an inconsistent level of GPRS service. In other words a service which was working (before the user roamed) will no longer be working even though the user has returned to the original network which provided GPRS service.

To avoid the SIM being invalidated unnecessarily TSG CN#11 agreed to a modification to the GPRS specifications, which allows a network to reject a mobile's GPRS Attach request with a new GMM cause code "GPRS services not allowed in the current PLMN". The new rejection cause value "GPRS services not allowed in this PLMN"(#14) can be indicated to the MS during GPRS attach, detach and RAU in a PLMN which does not offer GPRS roaming to that MS. When an MS receives this cause code it shall not attempt a new GPRS attach before entering a new PLMN on which it hasn't be rejected with the same cause after the last switch on. In order to memorise the PLMNs on which the MS has been rejected with #14, a new PLMN list is introduced, which should be deleted when the MS is switched off. The list is introduced in order to avoid subsequent registration attempts if either the MS (in class C mode), or the user (in class A/B mode) triggers a PLMN reselection after reception of #14.

All new GPRS mobiles shall support the handling of the new cause value within four months of the relevant specification (04.08 v6.14.0) being published by 3GPP.

To restore the SIM to proper operation for GPRS service the user needs to power off and on the mobile. As defined by the specifications, this resets the SIM to its original state and removes the information indicating that the SIM is invalid for GPRS service. The use of cause value #14 (or any other cause value which is not defined in the reference specification of the MS), towards some of the roaming legacy mobiles which were implemented prior to the date laid down in 5.2.3, operating in a network using Network Mode of Operation I (NMO I), may lead to those legacy mobiles not receiving service (see 04.08 subclauses 4.2.4.2.2 and 4.7.3.1.5). This means that the behaviour of some roaming legacy mobiles may be unpredictable in NMO I if cause value #14 is used towards those legacy mobiles.

It was found that the Early Classmark Sending Capability (ECSC) bit is present on BCCH in SI3 but is not present on PBCCH. If the MS considers that early classmark sending is not allowed by the network, it will not spontaneously send a CLASSMARK CHANGE message when a call is initiated, and the Classmark 3 IE will not be received by the network. This may result in that the MS will not receive expected service from the network based on actual MS capabilities. Three different mobile implementations have been identified for a GPRS R97 mobile on a PBCCH cell:

1. The MS systematically reads SI3 on BCCH and uses the ECSC value,
2. When the MS does not read SI3, it systematically sends early classmark message,
3. When the MS does not read SI3, the MS never sends early classmark message.

TSG GERAN#07 has agreed that the three mobile implementations are acceptable for a GPRS R97 MS.

The systematic reception of an early CLASSMARK CHANGE message shall be supported by the BSS, even though the BSS may ignore the content of the message.

The network may initiate a classmark interrogation procedure (see 3GPP TS 04.08) to get the Classmark 3 information from the MS.

It was found that the term "change of Kc" used in 3GPP TS 04.64 sec. 8.9.2 was interpreted differently. Two different mobile implementations have been identified for a GPRS R98 mobile for the case that the network uses the same authentication triplets twice:

1. the MS does not reset the IOV value to its default value, but keeps the current value;
2. the MS resets the IOV value to its default value.

TSG-CN1 Meeting #21has agreed that only the behaviour described in 5.4.1 a) is correct and has clarified this behaviour in the corresponding CR 04.64 A155.

All new GPRS mobiles shall support the correct behaviour of the IOV handling described above within four months of the relevant specification (04.64 v7.4.0) being published by 3GPP.

After the assignment of the same Kc value, in order to avoid different IOV values in the SGSN and the legacy mobile station, the SGSN may negotiate a random IOV value, after the authentication procedure is completed.

It has been found that the 'downlink' bit in the Dedicated Mode or TBF information element has been implemented differently. The Dedicated Mode or TBF information element is used in the IMMEDIATE ASSIGNMENT message on CCCH. The 'downlink' bit is significant at a packet downlink assignment using this message. If the mobile station has received a first IMMEDIATE ASSIGNMENT message where the Dedicated Mode or TBF information element indicates that this is the first message in a two-message assignment (3GPP TS 04.08), two different implementations have been identified for a GPRS R98 mobile station:

1. The mobile station expects a second IMMEDIATE ASSIGNMENT message with the 'downlink' bit set to '0' in the Dedicated Mode or TBF information element.
2. The mobile station expects a second IMMEDIATE ASSIGNMENT message with the 'downlink' bit set to '1' in the Dedicated Mode or TBF information element.

In each case, if there is no second IMMEDIATE ASSIGNMENT message received with the 'downlink' bit set to the expected value, the two-message assignment procedure fails.

TSG GERAN meeting #12 has agreed that the two implementations are acceptable for a GPRS R98 mobile station.

Not applicable to GPRS R98.

The network may avoid using the two-message assignment procedure for packet downlink assignment. If frequency hopping shall be applied and the direct encoding of the frequency parameters does not fit into a single IMMEDIATE ASSIGNMENT message, the network may use indirect encoding of the frequency parameters.

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: 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.