Silicon Investor (SI) -- The First Internet Community

STOCKTALK

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) -- Ignore unavailable to you. Want to Upgrade?

To: carranza2 who wrote (14770)	9/1/2001 6:16:12 PM
From: 49thMIMOMander	Read Replies (1) \| Respond to of 34857

Great, now we are getting to the real existence of ITU. The consensus of its members.

To: carranza2 who wrote (14770)	9/1/2001 9:13:11 PM
From: S100	Respond to of 34857

My, My, more problems? Nothing new, wonder how that always the same, never changing viewgraph on GPRS will look? snip Date 8thh of June, 2001 : The GSM TWG (Terminal Working Group) is very concerned about the lack of availability of GPRS terminals. One of the major factors is the problem of testing the GPRS broadcast control channel and it's other associated sub-features such as multiple configurations and Network Control Order 2. These features are so complex that live network testing is necessary for full verification. The basic issue is that these features were made mandatory in the terminals and optional for the network infrastructure. This has led to the problem that network infrastructure is not available to sufficiently verify the GPRS broadcast control channel and associated sub-features. These features will be very important to operators for capacity, traffic management and other reasons as GPRS traffic increases. The operators and terminal vendors have the following three choices. 1)Deploy terminals without any of these features then upgrade/replace a large number of terminals as these features are added to the network. 2)Deploy terminals which have a partially verified implementation of some of these features. which will also result in the upgrade/replacement a large number of terminals as the complete set of features are added to the network. 3)Delay GPRS deployment until all these features can be fully tested (including live network testing) None of these options are acceptable to operators (or should be to equipment vendors and subscribers). More delays in widespread GPRS deployment are not acceptable. GSM TWG requests that 3GPP take the following actions. 1) Examine the current GPRS situation and see if any changes are necessary. GERAN appears to be the appropriate working group. 2) All the working groups in 3GPP should be urged to ensure that similar situations do not occur with 3G. It is not acceptable that major complex features are optional in the network while mandatory in the terminals, unless a test and verification strategy has been developed. In such a situation those features should also be mandatory in the network. Delays of months or years are not acceptable in 3G environment. snip PS is there something wrong with my browser? Seems to be a large number of posts missing, removed for content problems?

To: carranza2 who wrote (14770)	9/1/2001 9:17:10 PM
From: S100	Respond to of 34857

Oh No, problems with GPS? Problem counting to 8 bits? snip To correct various faults related to A-GPS in this specification. 1) In the ASN.1 definitions the sequence number for ephemeris (IODE) is defined as to have values from 0 to 239. The upper limit for this should be 255, as per ICD-GPS-200, Table 20-XII. The limit of 239 is only applicable for "normal operations", which means the satellite has a recent upload of ephemeris data. If uploads are interrupted (due to war, operational problems, etc), the iode value could extend beyond 239. Obviously, history shows this condition has occurred rarely (if ever) during the 20 year history of GPS. It does not mean that a value larger than 239 will never be seen. This should be changed so that the upper limit is 255.2) Table A.13 shows 8 bits are required for the number of field types present. Table A.12 indicates there are actually 9 bits present, not 8. Table A.13 should be updated to show 9 bits for the number of fields types present.3) In table A.15, the SatID field (first parameter of the repeated portion of the message) shows a value range of 1-64. This should actually be 0-63 to match the descriptive text found on the next page and in the ASN.1 listing.4) Also in table A.15, the Delta RRC3 value shows a range of +/- 0.024. This should actually be +/- 0.224 to be consistent with the ASN.1 listing, comment for deltaRangeRateCor3.5) The description of Status/Health found under Table A.16 says:"The value '110' indicates that the source of the differential corrections (e.g., reference station or external DGPS network) is currently not providing information. The value '111' indicates that the corrections provided by the source are invalid, as judged by the source. In either case, the message shall contain no corrections for individual satellites. Any MS that receives DGPS Corrections in a GPS Assistance Data IE shall contain the appropriate logic to properly interpret this condition and look for the next IE."The underlined portion is not consistent with the original source of this information, found in SC-104, Version 2.2, dated Jan 15, 1998 and published by RTCM. That document indicates a value of '110' means "Reference Station Transmission Not Monitored", saying that the data is present, it has just not been independently verified. This is the common status code produced by DGPS receivers when an independent monitoring network has not been set up. It does not indicate the actual data is bad as the statement above would indicate. The value description should be updated to reflect SC-104.6) The descriptive text for IODE states:"This IE is the sequence number for the ephemeris for the particular satellite. The MS can use this IE to determine if new ephemeris is used for calculating the corrections that are provided in the broadcast message. This eight-bit IE is incremented for each new set of ephemeris for the satellite and may occupy the numerical range of [0, 239] during normal operations. For more information about this field can be found from [14]."The underlined portion is an incorrect statement. The reference to [14] indicates the ICD-GPS-200. In that document, paragraph 20.3.4.4 says that "… The transmitted IODE will be different from any value transmitted by the SV during the preceding six hours." There is nothing in here that actually indicates IODE values are incremented. Historical satellite data (not a simulator) obtained from the WWWeb (http://www.ngs.noaa.gov/CORS) shows that values do not increment. The text should be modified to reflect the real handling of IODE values.7) There is a reference to table A.17 in two locations. There is no Table A.17 in the entire document. That reference should be updated to A.15.8) In table A.19, the scale factor for Cuc and Crc are switched. The correct scale factors are (see table 20-III in ICD-200) Cuc: 2^-29 and for Crc: 2^-5. This should be corrected in table A.19.9) In the ASN.1 specification for the DGPS corrections IE a comments says that "value definitions in 04.72". This is incorrect (04.72 contains the supplementary service call deflection!), the value definition is contained in the annex of this specification. This note should be deleted.