1. 2003.08.18BCMC Functional Requirements for Release D1 TSG-C Working Group 2 Subject:Release D BCMCS Functional Requirements Source:Lucent Technologies Contact:D. N. Knisely, dnk@lucent.com Recommendation: Discuss and adopt as requirements for Release BCMCS features. Lucent Technologies grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner's name any Organizational Partner's standards publication even though it may include all or portions of this contribution; and at the Organizational Partner's sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner's standards publication. Lucent Technologies is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by Lucent Technologies to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on Lucent Technologies. Lucent Technologies specifically reserves the right to amend or modify the material contained herein and to any intellectual property of Lucent Technologies other than provided in the copyright statement above.

2. 2003.08.18BCMC Functional Requirements for Release D2 Overview Overview BCMCS Proposals Comparison of Basic Approaches LU Shared Traffic Channel Proposal Comparison of LU and QCOM STC Proposals LU Proposed Enhancements to QCOM F-BSCH BCMC Summary of BCMC Functional Requirements for Release D Summary of Required Standards Changes

3. 2003.08.18BCMC Functional Requirements for Release D3 Broadcast/Multicast Channels Air Interface BCMC Capabilities Under Development for IS-2000-D: –Idle Mode BCMC F-BSCH –based on Qualcomm proposal –Shared Traffic Channel (STC): Shared F-FCH/F-DCCH/F-SCH proposed by Lucent Subset of LU proposal recommended by Qualcomm (F-MFCH) (C30-20030714- 102_QCOMIS2000DynamicSharedChanne.pdf)

4. 2003.08.18BCMC Functional Requirements for Release D4 Comparison of Idle BCMC and STC (Idle BCMC and STC are Complementary, Not Alternatives) Idle BCMC (QCOM F-BSCH) –Highly Scalable No RL Overhead Unlimited Number of Receivers –Semi-dynamic Registration for Streams Flows can be Started on Demand, but Not in Real-time Delay for Stopping Flows –Issues with Operation while on Traffic Channel –Ad-Hoc Coverage (Static) Most Likely << 3G1X –Good Fit For: Streaming Media Streams of Data where Reliability and Coverage are not Critical Shared Traffic Channel (LU) –Optimally Efficient (FL) for BCMC Delivery: Only Necessary Legs Power Controlled – Minimal Possible Power from Each Leg –Requires RL, which Limits Scalability –Coverage Identical to 3G1X Voice/Data –Dynamic, Real-time SHO Supported –Normal Reverse Link from MS –Good Fit For: PtT (with Limited Scalability) BCMC Data Services (BCMC IP) Enhancements to 3G1X Data Services Using Existing H/W Lucent proposals to eliminate or mitigate.

5. 2003.08.18BCMC Functional Requirements for Release D5 Shared Traffic Channel Modes/ Configurations Shared ControlShared Traffic Shared F-FCH(Not Allowed) All MSs Assigned to Walsh Code Receive Common Traffic Stream Shared F-DCCH Traffic (Control/ Signaling) is TDMed between a Set of MSs Sharing a Common Walsh Code All MSs Assigned to Walsh Code Receive Common Traffic Stream Shared F-FCH and Shared F- DCCH SIG TDMed Individually to One MS at a Time + Traffic Multicast to All MSs Shared F-SCH(Not Applicable) All MSs Assigned to Walsh Code Receive Common Traffic Stream

6. 2003.08.18BCMC Functional Requirements for Release D6 Multicast Stream Example Configuration

7. 2003.08.18BCMC Functional Requirements for Release D7 Broadcast/Multicast Forward Traffic Channel Key Features 1.Shared F-DCCH for Forward Signaling –Unicast on a Shared Walsh Code –TDM by Long Code Mask (LCM) of Each MS 2.Shared F-FCH or F-DCCH for Forward Data Traffic –Multicast on a Shared Walsh Code and Shared LCM –Appropriate for Shared Voice and/or Data Streams 3.Shared F-SCH for Higher Rate Forward Data Traffic –Multicast on a Shared Walsh Code and Shared LCM –Appropriate for Shared Higher Rate Data Streams

8. 2003.08.18BCMC Functional Requirements for Release D8 Broadcast/Multicast Forward Traffic Channel Details 1.Sharing is on a Leg-by-Leg Basis –As far as the MS is concerned, each leg is being unicast to it. –BS may configure legs to be shared or non-shared according to whether: More than one MS needs a “copy” of the same stream of data, or More than one MS can share an F-DCCH Walsh code for control information. 2.Highly Dynamic Membership in Shared Streams; Data Traffic Channel May be Shared or Non-shared Independently on Each Leg 3.Forward Power Control Bits are Multiplexed on CPCCH to Control Multiple Reverse Links 4.Reverse Link Identical to 3G1X 5.Processing of Power Control Bits from MSs at BS is Not Specified by Standard; Could Use Various Techniques, e.g., “Or of Up Bits” 6.Note: Data == Any Voice, Data, or Combination in this Presentation

9. 2003.08.18BCMC Functional Requirements for Release D9 STC Benefits Excellent Fit for High Priority Applications: –Low Rate Multi-cast Datastreams (e.g., Information Services, Status/Traffic/Weather, Location- Dependent Info Directed to Many MSs) –High or Low Rate Multi/Broadcast Datastreams that are Accessible from the Traffic Channel –Push to Talk Compatible with Existing 3G1X Forward Link –BS (Esp. BTS) Re-use; Software-only Feature Compatible with Existing 3G1X Reverse Link –Potential Re-use of Existing ASICs with only Software Changes Straightforward A Interface Extensions; Minimal Changes (if Any) Synergistic with F-PDCH: –Shared F-DCCH for Signaling/Control is Beneficial for QoS Constrained Environments and when F- DCCH Variance is a Poor Match for Signaling Traffic Extremely Efficient Conservation of Walsh Codes Suitable for Gradual Introduction: –V1 => V2 (Shared DCCH; Dedicated FCH) => V2 w/CPCCH => V2 w/Shared F-FCH Robust: –Fallback to Conventional V2 or Even V1 as Needed; Transparent to MS –Seamless Transition from “Multi-Unicast” to Share Traffic Channel as Users who are Sharing the Datastream are Added

10. 2003.08.18BCMC Functional Requirements for Release D10 Comparison of LU and QCOM STC Proposals FeatureLUQCOM Shared F-DCCH for SIG/Control Shared F-FCH for Traffic Shared F-SCH for High-rate Traffic  (Must use shared F-FSCH; Idle only) F-CPCCH for Common Power Control; New Power Control Modes F-BSCH Accessible While on Traffic Channel  (Must use shared F-FCH) Variable Rate F-BSCH  R-FCH DTX - (Seems to be a good idea) SHO between Unicast Legs and BCMC Legs  (Requires handover to F-FCHs)

11. 2003.08.18BCMC Functional Requirements for Release D11 Lucent and QCOM STC Proposals Have Significant Commonality Agree on shared F-DCCH Agree on basics of shared F-FCH for traffic, but differences in details Disagree on requirement for shared F-SCH

12. 2003.08.18BCMC Functional Requirements for Release D12 Broadcast/Multicast Proposal Standards Issues/Activities Lucent has concerns about F-BSCH deficiencies for PtT and dispatch applications: 1.Must work when MS is on traffic channel – CRITICAL ITEM! Must pass “Broadcast Active Set” and BCMCS parameters in UHDM or on traffic channel Example: dispatcher voice or data stream 2.Requires dynamic registration/de-registration Required so that flows can be started and stopped based on presence or absence of MSs that are monitoring individual flows 3.Variable rate operation Undesirable/infeasible to reconfigure physical F-BSCH every time certain flows are started/stopped or for flows with a low duty cycle 4.Improved battery life for MSs monitoring mostly-idle broadcast streams (e.g., “QBPCH” concept) 5.MS feedback for system tuning

13. 2003.08.18BCMC Functional Requirements for Release D13 Dynamic Operation of Flows Example

14. 2003.08.18BCMC Functional Requirements for Release D14 1. Making the F-BSCH Operate while on Traffic Channel F-BSCH Reads all Operating Parameters from Overhead Channels MSs Can’t Monitor/Read Overhead Channels while on Traffic Channel Solution: –MS Registers for BCMC Flows while on TC –BS Includes Updated BCMC Overhead Parameters + “BCMC Active Set” with HDMs Issues: –MS Hardware Capable of Monitoring F-BSCH (with Unique Active Set) while Processing FCH/SCH/etc.

15. 2003.08.18BCMC Functional Requirements for Release D15 2. Dynamic Registration for F-BSCH F-BSCH Currently Provides No Reliable Registration/De- registration Procedures –Not Entirely a Bad Idea; Reduces Overhead on Common Channels and Improves Scalability –But, at Expense of Loss of Dynamic Control to Turn On/Off Streams –Not a Big Deal for BC Media Streams, but Bad for MC Data, PtT, etc. Solution: –Ericsson Proposed Reg/Dereg Enhancements for HRPD BCMC, which were Extended and Improved –Adopt Similar Scheme for F-BSCH –Not Perfect, but Provides Good Tradeoff between Overhead and Dynamic Control

16. 2003.08.18BCMC Functional Requirements for Release D16 3. F-BSCH Variable Rate Operation Problems: –F-BSCH Operates at Full Rate or Off (DTX) Only –F-BSCH Must be “Sized” for Max(# Flows that will be Concurrently Active) –Assuming Lots of Dynamic Small Flows (e.g., PtT), Most of the Time, F-BSCH is Running at Too High a Rate (and Consuming too Much Walsh Space, etc.) Solution: –Variable Rate Operation of F-BSCH –Blind Rate Detection (or Assisted, e.g., Rate Encoded in the Preamble or on a Control Channel)

17. 2003.08.18BCMC Functional Requirements for Release D17 4. Improved F-BSCH Idle Mode Battery Life F-BSCH Currently Optimized for MSs that are Continuously Monitoring a (Continuous) Stream or Nothing Not Well Suited to Low Occupancy, Long-term Services, e.g., Dispatch, PtT Streams, etc. Solution: –“Broadcast Quick Paging Channel”-like Approach for BCMC –MSs Monitor a Slotted Channel Looking for Indicators that Data for the MS’ Stream(s) is Available Issues: –Details –Schedule for Release D –May Need to Slip to Later Release (Can Use STC in Meantime)

18. 2003.08.18BCMC Functional Requirements for Release D18 5. F-BSCH MS Feedback Problem: –F-BSCH Currently Assumed to be Statically Provisioned to Meet Carrier’s Coverage and Error Rate Requirements –Requires Drive Testing (or Just Guessing) –Most Likely Results in Poor Coverage and Major Coverage Holes –No Service Quality Measurements at All! Solution: –MSs Provide “BPSMM” Reports Based on Defined Triggers E.g., “Stream Advertised, but Can’t be Decoded” or “Stream Advertised, but Experiencing High FER” MS Reports Pilot Strengths and Some Measure of the F-BSCH Legs MS Could Optionally Report Location Information Hysteresis Control to Severely Limit Reporting Frequency Explicit Request/Response Mode –Can be Used Dynamically or Semi-Statically to Tune F-BSCH Power Levels (or Just for Service Measurements)

19. 2003.08.18BCMC Functional Requirements for Release D19 Summary of Release D BCMC Functional Requirements 1.Both Idle Mode and STC Modes are Required 2.F-BSCH Proposal is an Adequate Foundation, but Need to Augment with the Following: –Must work when MS is on traffic channel –Dynamic registration/de-registration –Variable rate operation –Improved battery life for MSs monitoring mostly-idle broadcast streams (e.g., “QBPCH” concept) –MS feedback for system tuning 3.See No Reason to Reduce any of Functional Capabilities in LU STC Proposal (Note that Products May Implement a Subset): –Shared F-FCH for Traffic –Shared F-DCCH for Shared Control Channel –Shared F-SCH for Rates > 14.4 Kbps –Allow Combining of Uni-F-FCH Leg with Multi-F-FCH Leg 4.R-FCH DTXing from QCOM STC Proposal is a Good Idea

20. 2003.08.18BCMC Functional Requirements for Release D20 STC Required Standards Changes 1.New Power Control Modes: –F-CPCCH PC of Reverse Link; May Require Adjustment of Step Size Depending on Details of CPCCH Slotting 2.Multicast Long Code Mask for Shared Traffic Channel –Re-use/extension of PLCM Extensions in Release C? 3.BCMC Flow Access (Registration/De-registration/Discovery of Flows) –Identification of BCMC Flows is Carried in Bearer IP Data between MS and PDSN (per BCMCS Framework) –Stage 2 Proposal(s) on the Table in BCMCS Ad Hoc Group –Support of BCMC Registration/De-registration on Traffic Channel –Support for Mapping (Similar to LPM) of BCMC Flows onto Shared Traffic Channels 4.Need to Permit Decoupled Frame Offsets for F-DCCH/F-FCH/F-SCH –Mobile Station Capability Record(s) –STC-capable Indicator on Origination Message 5.Minimum Performance Specification Changes 6.Capability Indicators for Shared F-FCH, F-DCCH, or both 7.Mandatory/Optional Requirements Changes to Air Interface are Limited to Upper Layer Signaling –No Impact on PHY, MAC, LAC

21. 2003.08.18BCMC Functional Requirements for Release D21 Idle Mode BCMC Required Standards Changes (Relative to QCOM Proposal) 1.Operation when MS is on traffic channel: –Addition of BCMC overhead information in *HDM, *CAM (“Broadcast Active Set”) –Addition of registration/de-registration messages on TC 2.Dynamic registration/de-registration –Per modified Ericsson proposal (functionally equivalent to HRPD registration/de- registration) 3.Variable rate operation –Leaning toward blind rate determination –Signaling will limit possible rate choices to a small number 4.Improved battery life for MSs monitoring mostly-idle broadcast streams (e.g., “QBPCH” concept) –Proposal to follow 5.MS feedback for system tuning –Settable Triggers: FER (Settable Target); Eb/No threshold –Mark Flows to Indicate whether feedback applies or not –Hysteresis to severely restrict rate of messages –BS query directive (flow number, duration for attempt, periodic or single shot)