re: cdma2000 Release A and the Synch Channel BUG-aboo
It was most refreshing to finally hear from KDDI on the synch channel issue and hear them call a spade a spade, a BUG a bug, AMBIGUITY, ambiguity, and MISINTERPRETED early specifications misinterpreted ...
- the handset sometimes doesn't move to 1X paging channel in the Pre Add.0 Rel.0 or the Rel.0 system because of the BUG of 3GPP2 specification.
- LGE noticed the 3GPP2 specification BUGS and developed ... [later] handsets accordingly.
- The symptom 1 is due to the AMBIGUITY of the 3GPP2 specification and is not due to a manufacturer’s fault who developed handsets based on the 3GPP2 specifications.
- The symptom 2 is caused by the revision of specification to aid the Motorola and Nokia handsets which are developed based on the 3GPP2 specification which were MISINTERPRETED by them.
ftp://ftp.3gpp2.org/SC_OP/Working/SC_OP-0201/SC-20020124_Seoul/SC-20020124-025_KDDI_SyncCH_resolution.doc
I think it is interesting that Akira Matsunaga of KDDI has been appointed chair of the new Ad Hoc attempting to resolve the issue. He is one of the authors of the resolution quoted above and referenced below.
As you may recall KDDI (and NEC & Matsushita) abstained from the last ballot when a single additional vote would have carried the synch channel fix ...
Message 16877974
... they probably won't be abstaining if /when there is another ballot. As they state:
The Sync Channel Issue has been discussed for nearly half a year within 3GPP2 mostly at the TSG-C, however, an agreement has not been reached so far and a substantial impact on the release schedules is now prevalent. The contributor believes that now it is a time to consider deliberately what is most important to the whole CDMA Camp and a solution may be sought as soon as possible in order not to affect the reputation of CDMA Camp.
... they're ready to get on with it and have proposed what I consider to be a rather pragmatic solution:
Assuming that the number of those Pre Add.0 Rel.0 handsets which will be used for the 1X data-roaming in the Rel.A system with Sync channel solution is smaller than the total number of those Motorola’s and Nokia’s handsets to be affected by the Sync Channel Issue, the Sync channel solution should be incorporated in the Rel.A with a note explaining this solution is introduced in order to aid handsets which are developed based on the mistakenly interpreted 3GPP2 specifications.
The consequences of adopting the synch channel fixes is that certain early (unmodified) Korean 1xRTT models manufactured in compliance with a buggy and ambiguous specification may not work or may take a performance hit at some time in the future if those (unmodified) Korean handsets are used by their owners to roam in the United States. Likewise, I assume, legacy IS-95 handsets manufactured by Motorola, Nokia, (and possibly Sony) won't work on unmodified Korean 1xRTT infrastructure manufactured in compliance with a buggy and ambiguous specification.
The consequence of not adopting the Synch Channel fix for American carriers is that handsets manufactured to Nokia and Motorola prior to mid-year 2001 will not work on 1xRTT networks without the Synch Channel fix applied due to the fact that both misinterpreted Synch Channel parameters of the IS-95 standard way back when, and despite the fact that these handsets are type approved, have been through CDG triangle testing, carrier integration testing and perform (in most cases) well in a cdmaOne environment.
Bottom line is that some manufacturers and some carriers are going to be affected by the resolution of this dilemma.
<< Entertaining Lucent comments >>
"Entertaining" is an interesting word to describe the fact that Lucent appears determined that there will be a standards base fix, and as the largest manufacturer of CDMA infrastructure they are wise to set the flag they have set. Along with Qualcomm they have worked diligently through this process.
<< Seattle meeting is happening NOW. 307kbs here we come! >>
The sooner the better, and there is considerably more import to the Release A standard than an additional coding scheme that doubles peak throughput to 307kbs.
Hopefully this can be resolved in Seattle. It may not be. TSG-C approval of a SC AHG consensus solution may occur at a later date (mid-March).
KDDI did a nice job of defining the issues as they currently stand in this document titled "Analysis Of Impact On The MS and Infrastructure Caused By The Sync Channel Issue":
ftp://ftp.3gpp2.org/SC_OP/Working/Sync_Channel_0202/syncch_ahg_kddi_contribution.doc
Best,
- Eric - |
