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 : Qualcomm Moderated Thread - please read rules before posting -- Ignore unavailable to you. Want to Upgrade?


To: engineer who wrote (19531)2/25/2002 9:53:11 AM
From: engineer  Read Replies (1) | Respond to of 196553
 
Sprint continues to develop clear picture of 3G.....

clearstation.etrade.com

KANSAS CITY, Mo., Feb 25, 2002 (BUSINESS WIRE) -- Sprint's Third-Generation network, or 3G, will enable data services at peak speeds of 144 kilobits per second this year and up to 2 to 5 megabits per second within two years. The result will be a network that will dramatically enrich the whole wireless experience and provide capabilities that will allow users to conveniently take and send wireless photos.

To support these future imaging services, Sprint (FON, Trade), which operates the largest all-digital, all-PCS nationwide network and is the fastest growing wireless carrier, today announced an agreement with LightSurf Technologies to deploy the LightSurf Visual Intelligence Platform (VIP). When launched, the platform is designed to allow Sprint wireless customers to easily point, shoot and share images instantly and conveniently with family and friends using new wireless devices that capture images.

LightSurf's Visual Intelligence Platform is a comprehensive suite of scalable, secure and reliable core-technology software components. These technology components provide an exchange of digital photos and multimedia messaging using any Internet-ready, graphics-capable system.

"Sprint is clearly looking to deploy useful innovations -- with new, easy-to-use technology that creates real value. That's been one of our guiding principles in developing Sprint's 3G network," said John Garcia, senior vice president of sales and distribution for Sprint's wireless division. "Sprint's relationship with LightSurf is a key component in the deployment of 3G wireless imaging. Look to Sprint to connect the LightSurf platform to our nationwide 3G network to support the best devices and most convenient wireless imaging applications."

"The tremendous demand we are seeing for our visual communications services on a worldwide basis is proof that a picture or an instant photo-message is indeed worth a thousand words," said Philippe Kahn, Chairman and CEO of LightSurf Technologies, Inc. "The world is beginning to communicate visually over wireless networks and we are proud to be partnering with Sprint to launch wireless imaging on its 3G network."

Sprint demonstrated live 3G wireless imaging at the games in Salt Lake City using its live Third-Generation Network in combination with a Ricoh RDC-i700 camera and Novatel, Inc. Wireless PC Card. The demonstration is part of the Sprint Third Generation Experience, an educational mobile showcase that debuted at CES, featuring live and simulated 3G applications, devices and services that will be available following the nationwide launch of the Sprint Third Generation Network in mid 2002.

Sprint is a global communications company serving more than 23 million business and residential customers in more than 70 countries. With 80,000 plus employees worldwide and more than $26 billion in annual revenues, Sprint is widely recognized for developing, engineering and deploying state of the art network technologies, including the United States' first nationwide all-digital, fiber-optic network. Sprint's award-winning Tier 1 Internet backbone is being extended to key global markets to provide customers with a broad portfolio of scalable IP products. Sprint's high-capacity, high-speed network gives customers fast, dependable, non-stop access to the vast majority of the world's Internet content. Sprint also operates the largest 100-percent digital, nationwide PCS wireless network in the United States, already serving the majority of the nation's metropolitan areas including more than 4,000 cities and communities.

LightSurf is the leading provider of technology, solutions and applications for Instant Imaging and mobile multimedia. LightSurf solutions bring the power and immediacy of visual communications to businesses and individuals alike. LightSurf Instant Imaging solutions include instant photo-messaging services, security, health care and media distribution applications, as well as applications for entertainment and branded content distribution. LightSurf's unique patent pending Visual Intelligence Platform supports MMS, WAP, i-mode, and other leading communications standards. LightSurf's Instant Imaging solutions are currently deployed worldwide. LightSurf partners include Sprint (FON, Trade), (EK, Trade), Yahoo! JAPAN (4689), Qualcomm (QCOM, Trade), Motorola (MOT, Trade) and others. Headquartered in Santa Cruz, Calif., LightSurf is privately held. The company was founded in 1998 by leading industry visionary Philippe Kahn. For additional information regarding LightSurf, please visit our Web site at www.lightsurf.com.

This press release includes certain estimates, projections and other forward-looking statements. Future performance cannot be ensured. Actual results may differ materially from those in the forward-looking statements. The words "estimate," "project," "intend," "expect," "believe" and similar expressions are intended to identify forward-looking statements. You should not place undue reliance on forward-looking statements, which speak only as of the date of this press release. Sprint and Lightsurf are not obligated to publicly release any revisions to forward-looking statements to reflect events after the date of this press release or unforeseen events. Sprint provides a detailed discussion of risk factors in periodic SEC filings.


CONTACT: LightSurf Technologies, Inc.
Kate Dueck, 831/588-8973
kate.dueck@lightsurf.com
OR
Sprint Media Relations
Nancy Sherrer, 913/762-7032
nsherr@mail.sprintpcs.com
OR
Edelman PR
Victoria Archibald, 650/776-5755
Ed Tan, 650/429-2734
ed.tan@edelman.com
URL: businesswire.com
Today's News On The Net - Business Wire's full file on the Internet
with Hyperlinks to your home page.



To: engineer who wrote (19531)2/25/2002 10:28:23 AM
From: foundation  Read Replies (1) | Respond to of 196553
 
Corrections for the "completed" UMTS Release 99

==========

"..I have not seen a signed off r99 standard release.."

3GPP proponents will tell you it was completed and signed off ages ago.

Here are corrections for the "completed" Release 99 from the most recent TSG-RAN WG2 meeting (Orlando, FL, USA, 18 - 22 February 2002):

Some of these corrections reference Release 4, or Release 4 Reflector, but are all listed under "6 Corrections on Release '99". Releases 4 and 5 have their own sections of contributions ("8 Corrections on Release 4" and "9 Release 5 and beyond features"). These R99 corrections may impact R4 as well, and require cross-referencing...

I'd repeat, from an earlier post, that the WG chairman noted that there were so many Release 99 corrections that some would probably have to be delayed until the next meeting, so this was probably not all for this month.

But with Release 99 corrections, there is always next month... <ggg>

==========

6 Corrections on Release '99

6.1 Incoming LSs on Release '99
Liaisons on Rel-4 are captured under Agenda Item 8.1, liaisons on Rel-5 under Agenda Item 9.1.

6.1.1 TSG-RAN WG1
There was no input for this agenda item.

R2-020203 (R1-020193, to TSG-RAN WG2) Response to LS (T1-010552, T1-010554) on Additional RABs for 34.108 (TSG-RAN WG1)
Anders Berggren (Ericsson) presented this LS.
Discussion: There was no need to handle this LS, as it had been made obsolete by the joint meeting with WG1.
Decision: The LS was noted.

6.1.2 TSG-RAN WG3
R2-020206 (R3-013703, copy TSG-RAN WG2) Response to LS (R4-011663) on UTRAN SFN-SFN observed time difference measurement (TSG-RAN WG3)
Claudiu Mihailescu (Nortel Networks) presented this LS.
Discussion: There was nothing to do for WG2.
Decision: The LS was noted.

R2-020439 (R3-020694, to TSG-RAN WG2) Response to LS (S2-020276) on Restoration of R'96 Any Time Interrogation functionality (TSG-RAN WG3)
Alan Law (Vodafone Group) presented this LS.
Discussion: There would be CRs to 25.305. The CRs were the same, but which release depended on decisions in TSG-RAN plenary based on other groups' input.
Decision: The LS was noted.

6.1.3 TSG-RAN WG4
R2-020225 (R4-020488, to TSG-RAN WG2) LS on Physical layer measurement aspects and new concept of UP (TSG-RAN WG4)
Joerg Schniedenharn (Siemens) presented this LS.
Discussion: It was asked what should be done with UP in the WG2 specifications. There were other situations where performance requirements were not covered by WG4. It was probable that UE implentations of these features should fulfil the performance requirements as defined in later releases, but this was not formally written down. There were also inconsistencies with WG1.
Decision: The LS was noted. The topic needed to be resolved during this meeting, but no resolution was achieved.

R2-020226 (R4-020502, copy TSG-RAN WG2) Response to LS (GP-012843) on Number of UTRAN frequencies monitored by an MS (TSG-RAN WG4)
Thomas Balon (Nokia) presented this LS.
Discussion: This was the WG4 response to R2-020210. The signalling allowed something, but WG4 said that the UE behaviour was unspecified. The current text "shall be capable" was not clear in the sense that it did not limit monitoring to three frequencies. Some form of specification was in order.
Decision: The LS was noted. Francesco Grilli would draft a CR and a response in R2-020396.

6.1.4 TSG-SA and TSG-SA WGs
R2-020214 (S2-020276, copy TSG-RAN WG2) LS on Restoration of R'96 Any Time Interrogation functionality (TSG-SA WG2)
Alan Law (Vodafone Group) presented this LS.
Discussion: There was nothing to do for WG2, although WG3 had some work to do.
Decision: The LS was noted.

R2-020207 (S3-010682, to TSG-RAN WG2) Response to LS (R2-012400) on Message size limitation for f9 algorithm (TSG-SA WG3)
Norbert Kroth (Siemens) presented this LS.
Discussion: This was consistent with the current WG2 specifications.
Decision: The LS was noted.

R2-020362 (S3z020043, to TSG-RAN WG2) Response to LS (R2-012275) on START value calculation (TSG-SA WG3)
Ravi Kuchibhotla (Motorola) presented this LS.
Discussion: The decision on what was to be done was left to WG2, but TSG-SA WG3 wanted to know the final outcome.
Decision: The LS was noted. Ravi Kuchibhotla (Motorola) would draft a response in R2-020397.

6.1.5 TSG-CN and TSG-CN WGs
R2-020228 (N1-020414, to TSG-RAN WG2) Response to LS (N1-020172, R2-012777) on Retransmission of Uplink NAS messages from RAN2 (TSG-CN WG1)
Joakim Bergström (Ericsson) presented this LS.
Discussion: Ericsson had provided a CR related to this LS. If the suggestion from TSG-CN WG1 was followed, it looked like for PS domain the model would not be followed.
Decision: The LS was noted. The CR would be discussed as part of the appropriate agenda item.

6.1.6 TSG-T and TSG-T WGs
R2-020208 (T1-010488, to TSG-RAN WG2) LS on T1 proposed CRs to TS 34.109 (TSG-T WG1)
Anders Berggren (Ericsson) presented this LS.
Discussion: The title of the CRs was rather general.
Decision: The LS was noted. Anders Berggren (Ericsson) would provide CR 011 (R2-020398) and CR 012 (R2-020399), which were both considered agreed

R2-020209 (T1-010554, to TSG-RAN WG2) LS on Request for verification of parameters for a proposed RAB in T1 (TSG-T WG1)
Anders Berggren (Ericsson) presented this LS.
Discussion: This LS was obsolete.
Decision: The LS was noted.

R2-020423 (T1R020060r1, copy TSG-RAN WG2) LS on Deletion of power control algorithm 2 from R'99 (TSG-T WG1/RF) (see 4.3)

6.1.7 TSG-GERAN and TSG-GERAN WGs
R2-020210 (GP-012843, to TSG-RAN WG2) LS on Number of UTRAN frequencies monitored by an MS (TSG-GERAN)
Thomas Balon (Nokia) presented this LS.
Discussion: There was a response from WG4 in R2-020226.
Decision: The LS was noted.

6.1.8 ITU-R/ITU-T
There was no input for this agenda item.

6.2 General decisions
R2-020243 Problems in Cell/URA update and SRNS relocation (LG Electronics Inc.)
SeungJune Yi (LG Electronics Inc.) presented this document.
Discussion: It was agreed that this was a downlink problem. For uplink there was no problem, and although it could be nice to do it for uplink, that was not a correction and should not be done for R'99. For this A.1 and A.2 were proposed as solutions. Some delegates felt that A.1 did not work in all cases. Tdoc R2-020324 (CR 1303 to 25.331) argued that A.1 did not work. A.2 was thought to work.
Decision: The document was noted. Solution A.2 was chosen, for downlink, and SeungJune Yi (LG Electronics Inc.) and Kota Fujimura (NTT DoCoMo) would draft a CR to RLC.

R2-020256 Use of CELL FACH state for signaling towards the CS domain for Dual mode mobiles and 3G->2G cell reselection (NEC)
Michael Roberts (NEC) presented this document.
Discussion: It was recognised that there was a possible problem. To try to minimise the number of cases it happened was the best, which meant to minimise cell reselection as much as possible. With that, for uplink the third solution was acceptable.
Decision: The document was noted. Michael Roberts (NEC) would draft an LS to TSG-CN WG1 in R2-020400.

R2-020262 Correction to UE Id for DSCH (Nortel Networks)
Claudiu Mihailescu (Nortel Networks) presented this document.
Discussion: There had been a mistake in WG2 towards the end of 1999, which caused divergence between the situation in TSG-T WG1 and RRC/RLC. The problem only existed for FDD. If the TDD proponents believed that using C-RNTI would work in TDD, that could be used for FDD. There was concern that re-using C-RNTI might introduce unwanted side effects that could not be understood now. On the attached CR it was commented that CELL_UPDATE_CONFIRM had been forgotten.
Decision: The document was noted. It was agreed to go for a 16-bit solution and check that it would work for both FDD and TDD. Claudiu Mihailescu (Nortel Networks) would provide a revised CR to be handled under the appropriate agenda item.

R2-020293 Inclusion of interim test marker and release indicator in RRC (Ericsson)
Himke van der Velde (Ericsson) presented this document.
Discussion: The proposal was to include the information in the RRC CONNECTION REQUEST message although there was no strong preference. There was a discussion as to what exactly the TSG-RAN plenary had approved. Some delegates believed that the introduction of the interim test marker had been approved, but this was contested. A check of the report revealed that WG2 had been tasked to provide the relevant CRs for RRC, but there were concerns about this interim marker from several companies. It was therefore proposed to split the CR into two parts that could be agreed separately. With respect to the release indicator, it was confirmed that this had been agreed a few WG2 meetings ago. This was to avoid the UE having to try different versions of the same message to find out which release it was. A related CR to 25.306 also needed to be split for the same reason.
Decision: The document was noted. Himke van der Velde (Ericsson) would provide two revised CRs to be handled under the appropriate agenda item.

R2-020263 Correction to UP measurements (Nortel Networks)
Claudiu Mihailescu (Nortel Networks) presented this document.
Discussion: The UE GPS timing of cell frame was missing from some other IEs. There was some inconsistency within the WG1 specifications (according to 25.225 it was not possible to read it on another frequency). It was clarified that there were several contradictions, but also that a CR had been put into WG1 on this topic. Another solution could be to correct it only for the 'intra' case. WG1 was still discussing for the 'inter' case. If CELL_FACH state needed to be covered, the definition needed to be corrected also. UP measurement periodical reporting was left for further discussion. For Periodical reporting for UP event triggered, it was asked if only the value infinite could be kept. Francesco Grilli (Qualcomm) would check the Stage 2 to see if there were any requirements for the other values.
Decision: The document was noted.

R2-020390 Considerations and corrections to UP measurements (Nokia)
Juha Mikola (Nokia) presented this document.
Discussion: It seemed it could be possible to solve this without joint session. However, in WG1 there were also voices to keep the active set definition. Opinion in WG2 seemed to be that this was needed for CELL_FACH state. Decoupling of RRM and UP was a good thing and would make life easier. It was asked why GPS was proposed to be removed, as this was complete, and why was anything to be removed from Rel-4 (implementation of Rel-4 was not yet at a stage that it was needed; absence of performance requirements was not a reason as there were examples such as RACH in R'99 which were used but with the performance requirements in a later release).
Decision: The document was noted.

R2-020326 Open issues list on Security (Ericsson)
This document was revised by R2-020394.

R2-020394 Open issues list on Security (Ericsson)
Johan Torsner (Ericsson) presented this document.
Discussion: The draft CR capturing the current status was R2-020393. The CN domain switch issue was an important one to resolve (see R2-020288). Other issues remained open.
Decision: The document was noted. A revision was provided in R2-020463.

R2-020463 Open issues list on Security (Ericsson)
Johan Torsner (Ericsson) presented this document.
Discussion: The item 2.40 was proposed to be closed (it was not integrity protected anyway).
Decision: The document was noted. The proposal to close 2.40 would be included in the LS to TSG-SA WG3.

R2-020288 Security at CN domain switch (Alcatel)
Patrick Fischer (Alcatel) presented this document.
Discussion: The proposal had isolated impact (security). It was asked if 'algorithm 0' was a case that was different from 'stop ciphering' (were there two cases for the same situation?). The question was whether more than one algorithm was supported. It was clarified that at the moment a change between two algorithms was not supported. It was felt that it was necessary to be able to support more than one algorithm to be future-proof. An example was that the algorithm could be compromised at some time, forcing a change of algorithm. It would save some problems to consider algorithm 0 only, and not the 'stop ciphering', which caused some headaches when restarted. There was preference for Solution III (see R2-020290 for the relevant CR).
Decision: The document was noted. It was agreed to use Solution III.

6.3 Proposed changes on 25.301
CRs to 25.301
There was no input for this agenda item.

6.4 Proposed changes on 25.302
CRs to 25.302
R2-020313 Revised CR 120 to 25.302 on Removal of no coding option <CR 121 Rel-4> (Siemens)
Norbert Kroth (Siemens) presented this CR.
Discussion: This was the first of a set of 'special' CRs, for which only technical correctness was checked. The source would be left as is, because TSG-RAN WG2 could give the impression that there was consensus. Technically, a few small errors were identified.
Decision: With these changes, the CR was technically endorsed. The update would be in R2-020408 (R'99) and R2-020409 would contain the Rel-4 shadow CR. Denis Fauconnier (Chairman) would draft an LS to explain the status of these CRs to the RAN plenary.

R2-020408 Technically endorsed CR 120r1 to 25.302 on Removal of no coding option <CR 121 Rel-4> (Siemens)
R2-020409 Technically endorsed CR 121 to 25.302 [Rel-4 shadow] on Removal of no coding option (Siemens)
Decision: The CRs were technically endorsed. <CHANGE CATEGORIES TO C>

R2-020335 Revised CR 123 to 25.302 on Clarification of layer 3 filtering of measurements in UE <CR 124 Rel-4> (Motorola)
Richard Burbidge (Motorola) presented this CR.
Discussion: It was commented that it was strange to limit the number of filtering coefficients by having only per quantities. There were other ways of achieving this.The proposal was to limit the number of filters. Perhaps it was best to limit this by type. Perhaps 25.302 was not the correct place to put this information. In RRC perhaps this was a good time to start a new informative annex on invalid configurations as had been discussed in the joint WG1/WG2 meeting on R'99 clean-up. It seemed that perhaps a complete review of the BCCH on this type of problems was in order.
Decision: An update of the CR was needed. The update would be in R2-020407. Richard Burbidge (Motorola) would try draft a CR to RRC and would also review BCCH to identify the problems.

R2-020407 Withdrawn CR 123r1 to 25.302 on Clarification of layer 3 filtering of measurements in UE <CR 124 Rel-4> (Motorola)
This document was withdrawn.

6.5 Proposed changes on 25.303
CRs to 25.303
R2-020234 Revised CR 063 to 25.303 on Correction on the RRC connection establishment procedure <CR 064 Rel-4> (Huawei)
Ping Zhang (Huawei) presented this CR.
Discussion: There was an editorial comment.
Decision: With these changes, the CR was agreed. The update would be in R2-020433 (R'99) and R2-020434 would contain the Rel-4 shadow CR.

R2-020433 Agreed CR 063r1 to 25.303 on Correction on the RRC connection establishment procedure <CR 064 Rel-4> (Huawei)
R2-020434 Agreed CR 064 to 25.303 [Rel-4 shadow] on Correction on the RRC connection establishment procedure (Huawei)
Decision: The CRs were agreed.

R2-020289 Agreed CR 066 to 25.303 on Alignment of SRNS relocation in CELL_DCH <CR 067 Rel-4> (Alcatel)
Patrick Fischer (Alcatel) presented this CR.
Decision: The CR was agreed. R2-020539 would contain the Rel-4 shadow CR.

R2-020539 Agreed CR 067 to 25.303 [Rel-4 shadow] on Alignment of SRNS relocation in CELL_DCH (Alcatel)
Decision: The CR was agreed.

R2-020417 Agreed CR 068 to 25.303 on Corrections on combined Cell/URA update and SRNS relocation <CR 069 Rel-4> (LG Electronics Inc., NTT DoCoMo)
SeungJune Yi (LG Electronics Inc.) presented this CR.
Decision: The CR was agreed. R2-020435 would contain the Rel-4 shadow CR.

R2-020435 Agreed CR 069 to 25.303 [Rel-4 shadow] on Corrections on combined Cell/URA update and SRNS relocation (LG Electronics Inc., NTT DoCoMo)
Decision: The CR was agreed.

6.6 Proposed changes on 25.304
CRs to 25.304
R2-020257 Agreed CR 095 to 25.304 on Correction to TDD paging message receiving occasion <CR 096 Rel-4> (IP Wireless)
Tim Speight (IP Wireless) presented this CR.
Discussion: Vodafone Ltd originally objected to this CR, but withdrew the objection.
Decision: The CR was agreed. R2-020448 would contain the Rel-4 shadow CR.

R2-020448 Agreed CR 096 to 25.304 [Rel-4 shadow] on Correction to TDD paging message receiving occasion (IP Wireless)
Decision: The CR was agreed.

R2-020294 Revised CR 097 to 25.304 on Clarification of IMSI at Paging channel selection and DRX calculation <CR 098 Rel-4> (Ericsson)
Anders Berggren (Ericsson) presented this CR.
Discussion: The ambiguity was not resolved if the word "decimal" was not mentioned (it could be understood that it was "hexadecimal where A..F was not used"). It would also help to add the example. For the case of the USA, the three-digit MNC used value 15 to be equivalent to 0. It needed perhaps to be checked that this case was not problematic.
Decision: An update of the CR was needed. The update would be in R2-020410.

R2-020410 Agreed CR 097r1 to 25.304 on Clarification of IMSI at Paging channel selection and DRX calculation <CR 098 Rel-4> (Ericsson)
Anders Berggren (Ericsson) presented this CR.
Decision: The CR was agreed. R2-020555 would contain the Rel-4 shadow CR.

R2-020555 Agreed CR 098 to 25.304 [Rel-4 shadow] on Clarification of IMSI at Paging channel selection and DRX calculation (Ericsson)
Decision: The CR was agreed.

6.7 Proposed changes on 25.305
CRs to 25.305
R2-020333 Withdrawn CR 076 to 25.305 on Description of Ephemeris Update Methods <CR 077 Rel-4; CR 078 Rel-5> (Motorola)
Yilin Zhao (Motorola) presented this CR.
Discussion: The most obvious way of receiving the ephemeris (from the satellite directly) was missing. It was commented that there was no need to specify any methods as they did not impact the interface. It could be written as examples also to show this. The RRC CR that should accompany this CR was currently missing. On the bullet in 10.5.1.4 "Request an entire set of ephemeris...", the number of satellites and the fact that data could be large were not really needed. In the bullet "Request only the newly arrived ephemeris...", all from "To do this extension..." could be deleted. There was no consensus.
Decision: The CR was withdrawn.

R2-020405 Agreed CR 079, Agreed CR 080 [Rel-4] and Agreed CR 081 [Rel-5] to 25.305 on Positioning when UE is not reachable (Vodafone Ltd)
Alan Law (Vodafone Ltd) presented this CR.
Discussion: The three CRs were agreeable based on R2-020439 (LS R3-020694) but depended on approval in the plenary pending actions in other groups.
- If approved for R'99, the R'99 CR would be Category F and the Rel-4 and Rel-5 CRs Category A.
- If approved for Rel-4, the R'99 CR would not be implemented, the Rel-4 CR would be Category F and the Rel-5 CR would be Category A.
- If approved for Rel-5, the R'99 and Rel-4 CRs would not be implemented and the Rel-5 CR would be Category F.
Decision: The CRs were agreed. Whether they were category F or category A depended on the plenary and would be handled accordingly.

R2-020494 Agreed CR 082 and Agreed CR 083 [Rel-4] to 25.305 on Correction to Cell_ID positioning when UE is not reachable (Nokia)
Juha Mikola (Nokia) presented this CR.
Discussion:
- If the CRs in R2-020405 were approved for Rel-5, this R'99 CR would be Category F and the Rel-4 CR Category A.
- If the CRs in R2-020405 were approved for Rel-4, this R'99 CR would be Category F and the Rel-4 CR would not be implemented.
- If the CRs in R2-020405 were approved for R'99, neither this R'99 CR nor this Rel-4 CR would be implemented.
Decision: The CRs were agreed. Whether they were category F or category A depended on the plenary and would be handled accordingly.

continued...