SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Nokia (NOK)
NOK 6.270-1.4%Dec 12 9:30 AM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: 49thMIMOMander who wrote (13966)7/19/2001 6:52:15 AM
From: Clarksterh  Read Replies (2) of 34857
 
llmarinen: If the power control is slightly off, for a moment, under heavy load, the most critical handsets are
lost, affects everyone.


Certainly agree that a runnaway handset is off in it's power control a bunch of other handsets will lose lock - although I don't know what "most critical handsets" means. But the same is true of a TDMA based handset in the time domain - if it forgets itself and broadcasts in the wrong timeslots. Which is more probable? That a CDMA phone loses power lock to the extent that other phones are affected or a TDMA phone loses time lock (again to the extent that other phones are affected)? Not at all obvious. An individual phone really has to go hog-wild in either case. I hardly think it is useful to a system to try to accomodate (other than by shutting down a problematic handset) a problematic handset by giving them more room.

The handset has to forward and reverse the timing, position of it's TX time slot so that all time slots
arrive non-overlapping to the basestation, which tells them what to do.


Well that I knew, but that is not the same as ensuring that the forward and reverse timeslots are timed in order to avoid the handset sending at the same time it is receiving. And of course at the basestation no such accomodation is possible in any case.

Clark
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext