Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x
Top   in Index   Prev   None

TR 49.995
GPRS – Interworking between Modified PLMN supporting GPRS
and Legacy GPRS mobiles

Use "3GPP‑Page" to get the Word version, and "ETSI‑search" to get the PDF version
V16.0.0 (PDF)  2020/06  13 p.
V15.0.0  2018/06  13 p.
V14.0.0  2017/03  13 p.
V13.0.0  2015/12  13 p.
V12.0.0  2014/09  13 p.
V11.0.0  2012/09  13 p.
V10.0.0  2011/04  13 p.
V9.0.0  2009/12  13 p.
V8.0.0  2008/12  13 p.
V7.0.0  2007/10  13 p.
V6.0.0  2005/04  13 p.
V5.0.0  2005/04  8 p.
V4.0.0  2005/04  8 p.
GSM Rel-99 v8.0.0  2005/04  8 p.
GSM Rel-98 v7.4.0  2005/04  8 p.
GSM Rel-97 v6.4.0  2005/04  8 p.
Rapporteur:
Mr. Andersen, Niels Peter SkovAnemone Technology

Content for  TR 49.995  Word version:  16.0.0

Here   Top

1  ScopeWord‑p. 5

This report describes issues relating to the GPRS specifications, which lead to the specifications being modified after the placement of GPRS compliant mobiles into the market place.
Where possible the present report clarifies any recommended measures which may be adopted by the GPRS infrastructure to enable interworking to be obtained between the GPRS infrastructure and legacy Mobile Station (MS) implementations of the GPRS specifications.
For each issue this report also defines the time after which all new GPRS mobiles are required to meet the modified specifications.
The lifetime of the herein described measures together with their potential impact on optimal network performance is out of the scope of the present document.
Up

2  References

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
Up

3  Abbreviations

Abbreviations used in the present document are listed in TR 21.905.

4  General

In the implementation of the GPRS standard it has been found that some aspects of GPRS have not been fully covered and as a result late changes have been made to the specifications.
This has lead to the situation where existing GPRS mobiles (i.e. those already in the field) no longer aligned with the latest version of the specifications. These 'legacy' mobiles will not be modified; however, where possible the present report clarifies any recommended measures which may be adopted by the GPRS infrastructure to enable interworking to be obtained between the GPRS infrastructure and these legacy Mobile Station (MS).
In addition and to ensure sufficient time for implementation and testing of modified GPRS implementation (MS and network) this TR specifies the point in time at which the specification modification come into force. After this point in time all new GPRS mobiles will be required to support the modified specification and all GPRS networks will be expected to handle the new mobile behaviour correctly.
The remainder of this TR describes how to overcome the possible impacts of the above factors.
Up

5  Specific implementation on the radio interfaceWord‑p. 6

5.1  MS behaviour during one phase contention resolution

5.1.1  Justification

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

5.1.2  Solution

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

5.1.3  Implementation requirements

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.

5.1.4  Support of Legacy mobiles

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.

5.2  Roaming

5.2.1  Justification

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

5.2.2  SolutionWord‑p. 7

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

5.2.3  Implementation requirements

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.

5.2.4  Support of Legacy mobiles

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

5.3  Early Classmark Sending on PBCCH cell

5.3.1  Justification

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

5.3.2  Solution

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

5.3.3  Implementation requirements

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.

5.3.4  Support of Legacy mobilesWord‑p. 8

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

5.4  Conditions for IOV reset

5.4.1  Justification

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.

5.4.2  Solution

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.

5.4.3  Implementation requirements

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.

5.4.4  Support of Legacy mobiles

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.

5.5  Two-message packet downlink assignment on CCCH

5.5.1  Justification

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

5.5.2  Solution

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

5.5.3  Implementation requirementsWord‑p. 9

Not applicable to GPRS R98.

5.5.4  Support of Legacy mobiles

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.

5.6  Negotiation of SNDCP compression entities

5.6.1  Justification

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

5.6.2  Solution

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.

5.6.3  Implementation requirements

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.

5.6.4  Support of Legacy mobiles

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

$  Change HistoryWord‑p. 11


Up   Top