Outline

1. Outline • Overview • IS-2000 Sync Channel Issue • Motorola “28 octet” problem • Motorola “32 octet” problem • Release 0 “Workaround” (FYI) • Release A Standards-based Solution • Performance Impacts • Calculation methodology • 4 case studies • Roaming Impacts

2. IS-2000 Sync Channel Issue • The IS95 Sync Channel Message length is increased in IS2000 Release 0 (11 bits) and Release A (additional 3 to 70 bits) • Legacy IS95 mobiles from more than one manufacturer (Including Motorola and Nokia) experience problems when Sync Channel Message length is extended beyond 27 octets (IS95 length) • Problems differ depending on manufacturer & message length • There are two issues associated with Motorola IS95 CDMA mobiles (to be summarized in following slides) • All currently shipping product has the issues corrected

3. Motorola “28 octet” Issue • Experienced when Sync Channel Message exceeds 27 octets (i.e. IS2000 Release 0 and beyond) • Can result in mobile failing to acquire Paging Channel of preferred system (acquires service on “less preferred” system): 4% of time • Can result in delay in acquiring Paging Channel of preferred system: 30% of time • Expected behavior of affected Motorola mobiles • 66% No impact (PCH/BCCH acquired immediately after Sync Channel) • 22% About 4sec delay to acquire PCH/BCCH after acquiring Sync • 8% About 7sec delay to acquire PCH/BCCH after acquiring Sync • 4% PCH/BCCH of most preferred channel not acquired, acquires next channel in PRL

4. Motorola “32 octet” Issue • Experienced when Sync Channel Message exceeds 31 octets (i.e. IS2000 Release A) • Sync Channel Message exceeds 31 octets ONLY in networks that support Transmit Diversity (TD) and/or 3X channels. • When 31 octets is exceeded, the problem Motorola mobile will reject the Sync Channel Message as too long • Expected behavior of affected Motorola mobiles • 100% Release A CDMA channel never acquired, less preferred IS95 CDMA channel or AMPS channel acquired instead (based on channels in the PRL)

5. Release 0 “Workaround” (FYI) • “Workaround” needed since Release 0 Sync Channel Message is 28 octets • Interim solution co-developed by Motorola, Lucent, Nokia, and Nortel • IS-2000 capable BS sends Sync Channel Message with PREV=5 (IS95B) • “True” PREV sent in Extended System Parameters Message on PCH • Extended CDMA Channel List Message is sent on PCH to force Release 0 mobiles to hash to 3G carrier • No change to standards, but technically non-compliant to IS-2000-0 since PREV set to 5 in Sync Channel Message (i.e. “workaround”) • Verification testing is well progressed • Relation to Release A: • Does not work for Release A, since information about Release A capable frequencies (BCCH, Transmit Diversity, 3X) not currently available on PCH • Release A solution proposed by Motorola is similar to Release 0 “workaround”, but adds BCCH/TD/3X information on PCH

6. Release A Standards-based Solution • Why a standards-based solution? • Problem affects a “significant” number of legacy mobiles • Recall would impact smooth evolution to IS2000 • Standards fix desirable, if there are not “significant’ performance trade-offs • Standards-based solution, developed jointly between Motorola and Qualcommand supported by Nokia, adds a third Sync Channel deployment “scenario” to the 2 currently existing in Release A: Scenario #1: No problem mobiles SCHM message length not an issue, Currently supported Scenario #2: “32-octet” problem mobiles AND TD/3X deployed SCHM message length < 32 octets, Currently supported Scenario #3: “28-octet” problem mobiles SCHM message length < 28 octets (i.e. IS95 length), NEW

7. Proposed Standards Changes • Add new BCCH Channel List Message to both BCCH and PCH • Allow MS to go directly to Idle State after successful release of traffic channel (and SID, Band Class have not changed) • Other minor changes and bug fixes • No current functionality is being removed

8. Summary of Impacts • In the short-term (where problem mobiles exist) • Extra “hop” may be needed to go from Sync to appropriate CDMA Channel • In some multi-carrier configurations, the extra “hop” is needed anyway (see case #3) • This impact is greatly mitigated by allowing MS to go directly to Idle from Traffic, thus avoiding Sync Acquisition • Average worst case delay for extra “hop” (if required) is 690-700 ms to reach BCCH/F-CCCH for pages (see case studies) • 0.7% to 1.7% increase in PCH loading, depending on configuration • In the long-term (where problem mobiles do NOT exist) • Standard is improved (Sync acquisition success rate improved, time away from PCH/F-CCCH reduced) • BCCH Channel List Message obsoleted on PCH

9. Deployment Scenarios: Case Studies • Assumptions • 28-octet problem mobiles exist in network • BCCLM sent once every 1.28 seconds (minimum requirement for overhead messages). NOTE: this minimizes PCH loading but maximizes average delay to reach BCCH. • SPM & ESPM must be received before BCCLM. • PCH is 9600 bps, overhead messages received on first try without error

10. Performance-impact:calculation methodology • PCH loading due to BCCLM • (# bits in BCCLM) / (9600bps x 1.28sec) • # bits in BCCLM = 32 bits (Layer 2) + Layer 3 Message fields + padding • Minimum message length is 80 bits (1 BCCH Freq), length increases with additional frequencies and mix of capabilities • BCCH loading due to BCCLM • NONE (BCCLM replaces existing ECCLM) • Delay to reach final BCCH/F-CCCH (where pages are expected) • (time to receive ESPM & SPM) + (time to receive BCCLM) • Minimum length of SPM is 256 bits, including Layer 2 fields • Minimum length of ESPM is 152 bits, including Layer 2 fields (assumes no optional fields except QPCH-related fields) • Time to receive ESPM & SPM is therefore 408 bits / 9600 bps = 42.5 ms • NOTE: By allowing MS to go directly to Idle State after call release, this delay is incurred very infrequently since Sync Acquisition is avoided.

11. Case #1 1 Frequency: supports both PCH and BCCH Scenario #1 • Release A mobiles listen immediately to BCCH Scenario #3 • Release A mobiles first listen to PCH to get BCCH parameters, then switch to BCCH • BCCLM is sent on PCH and BCCH (10 octets) • PCH loading increased by 80 bits every 1.28 secs (0.65%) • “Delay” for Release A mobiles to reach BCCH: • Minimum = 42.5 ms + (80 bits / 9600 bps) = 50.83 ms • Maximum = (1.28 sec + 50.83 ms) = 1.331 sec • Average “maximum” delay = 690.83 ms

12. Case #2 2 Frequencies: (1) PCH only, and (2) BCCH only Scenario #1 • All Release A mobiles go directly to Freq #2 Scenario #3 • All Release A mobiles go to Freq #1, then hash to Freq #2 • BCCLM is sent on PCH and BCCH (11 octets) • PCH loading increased by 88 bits every 1.28 secs (0.72%) • “Delay” for Release A mobiles to reach BCCH: • Minimum = 42.5 ms + (88 bits / 9600 bps) = 51.67 ms + time to tune to Freq #2 • Maximum = 1.28 sec + 51.67 ms = 1.332 sec + time to tune to Freq #2 • Average “maximum” delay = 691.67 ms + time to tune to Freq #2

13. Case #3 3 Frequencies: (1) PCH only, and (2 & 3) BCCH only Scenario #1 • All Release A mobiles go directly to Freq #2, then 50% hash to Freq #3 Scenario #3 • All Release A mobiles go to Freq #1, then 50% hash to Freq #2 and 50% hash to Freq #3 • BCCLM is sent on PCH and BCCH (13 octets) • PCH loading increased by 104 bits every 1.28 secs (0.85%) • “Delay” for Release A mobiles to reach BCCH: • Minimum = 42.5ms + (104 bits / 9600 bps) = 53.33 ms + time to tune to Freq #2 or 3 • Maximum = 1.28 sec + 53.33 ms = 1.333 sec + time to tune to Freq #2 or 3 • Average “maximum” delay = 693.33 ms + time to tune to Freq #2 or 3 • Note that even in scenario #1, 50% of RelA mobiles must hash, so scenario #3 impacts only 50% of Release A mobiles.

14. Case #4 3 Frequencies: (1) PCH only, (2) BCCH only, (3) TD only Scenario #1: all Release A mobiles go directly to Freq #2 or Freq #3, depending on their capability Scenario #3: all Release A mobiles go to Freq #1, then hash to either Freq #2 or Freq #3 depending on their capability • BCCLM is sent on PCH and BCCH (15 octets) • PCH loading increased by 120 bits every 1.28 secs (0.98%) • “Delay” for Release A mobiles to reach BCCH/TD: • Minimum = 42.5 ms + (120 bits / 9600 bps) = 55 ms + time to tune to Freq #2 or 3 • Maximum = 1.28 sec + 55 ms = 1.335 sec + time to tune to Freq #2 or 3 • Average “maximum” delay = 695 ms + time to tune to Freq #2 or 3

15. International Roaming Issues • If Scenario #3 is NOT deployed: • Motorola IS-95 mobiles with the 28-octet problem can roam internationally, as long as the roaming network has a Sync Channel Message with a length that is less than 32 octets. Currently shipping IS-95 mobiles have problem fixed. • Worst impact in roaming networks with Sync Channel Message length between 28 and 32 octets would be delay in acquisition of service. • In roaming networks with Sync Channel Message length >= 32 octets, the impacted Motorola IS-95 mobile would not acquire service. • If Scenario #3 is deployed: • All IS-95 mobiles will gain service without delay • All IS-2000-0 mobiles will gain 3G service after receiving ECCLM, with minor delay. • All IS-2000-A mobiles compliant with proposed changes will gain 3G service after receiving BCCLM, with minor delay.