500 likes | 646 Views
Enterprise FemtoCell Requirements (V0.4). November 25, 2009 Chris Osborn (AirWalk). Includes Contributions From: Chris Osborn (AirWalk) Bjorn Bjerke (Qualcomm) Serge Manning (Sprint) Doug Knisely (Airvana) Others Includes San Diego WG1/WG3 review comments. Overview Of Purpose.
E N D
Enterprise FemtoCellRequirements(V0.4) November 25, 2009 Chris Osborn (AirWalk) • Includes Contributions From: • Chris Osborn (AirWalk) • Bjorn Bjerke (Qualcomm) • Serge Manning (Sprint) • Doug Knisely (Airvana) • Others • Includes San Diego WG1/WG3 review comments
Overview Of Purpose • Develop a set of requirements and needs for Enterprise femtocell systems • Incorporate generic needs from multiple operator/vendor points of view • Can also incorporate some specific needs if definable from a high level • Requirements are functional, not decomposed to fundamental elements • Requirements to be universal and independent of specific RF technology • Focus on the high level functional needs; Should transcend CDMA/UMTS/Other • Note this does not preclude supplementary technology related requirements where directly applicable, but the intention is to avoid this to start • For example, isolate a topology requirement from a specific RF technology or device capability, then accept limitations after the fact • Examine requirements from three key perspective views: • Femtocell product; Femtocell network; Femtocell installation & deployment • Identify areas for potential WG2/WG3/WG4 detailed work activities • Phase 2: Requirements outputs to relevant SDO, if required
Execution Plan • Launched October 1 via SIG call • Driven by WG1 work item created as a result of 3GPP2 inputs request • Periodic review points with WG1 and SIG teams • Joint WG1/WG3 review at San Diego • Presentation of interim conclusions at San Diego WG1 sessions • Identify potential WG2/WG3/WG4 work items • Determine next steps at San Diego session • Revisions, informative input to SDO San Diego Plenary Launch Primary Inputs w/e 10/2 w/e 10/9 w/e 10/16 w/e 10/23 w/e 10/30 w/e 11/6 w/e 11/13 w/e 11/20 Next Steps > Review 1 Review 2
User Densities Examples • Various User Density Examples • British Council for Offices: Recommendations for average workplace density • 10m2 per person new building targets (8-13m2 typical) • Historical density increase:16.7 m2 in 1997 declining to 11.8 m2 in 2009 • EPA BASE Study (94-98): Air Quality Assessment of 100 buildings • 1.4-8.4 persons/1000ft2; Median 3.4; Inter-quartile 2.7-4.7/1000 ft2 • Median 290 ft2/person (Inter-quartile 210-370 ft2/person) • Seattle Energy Code Recommendations For Buildings • Assembly halls: 50 ft2/person • Restaurants: 100 ft2/person • Hotels: 250 ft2/person • Offices 275 ft2/person • Manufacturing: 750 ft2/person • Portland-Vancouver Planning Department • Wholesale/warehouse: 1500 ft2/person • Consolidate above numbers on a chart
Back Up: User Densities Source Data British Council For Offices EPA BASE Study Seattle Energy Codes Portland-Vancouver Planning Dept
Assembly Halls (50ft2/Person) Restaurants (100ft2/Person) Persons 120 BCO Office (108ft2/Person) US Office/Hotel (275ft2/Person) 110 CoverageDensity By Venue Type Manufacturing (750ft2/Person) 100 90 80 70 60 Warehouse (1500ft2/Person) 50 40 Large Whse (3000ft2/Person) 30 R 20 A 10 Assume Square Building; Cut the Chords 10 0 Area (ft2) 10k 20k 30k 40k 50k 60k 70k 80k 70’ 100’ 122’ 140’ 158’ 173’ 187’ 200’ Range (ft)
Restaurants (100ft2/Person) Assembly Halls (50ft2/Person) Persons BCO Office (108ft2/Person) 120 32 Channel FemtoCell 110 Femto CapacityExample US Office/Hotel (275ft2/Person) Manufacturing (750ft2/Person) 100 90 80 • Substitution Model • High Use Model • Users: 100% • Load: 200mE • GOS: 2% • N=4: 5 users • N=8: 18 users • N=16: 49 users • N=32: 118 users 70 60 Warehouse (1500ft2/Person) 16 Channel FemtoCell 50 40 Large Whse (3000ft2/Person) 30 8 Channel FemtoCell 20 10 4 Channel FemtoCell 10 0 Area (ft2) 10k 20k 30k 40k 50k 60k 70k 80k 70’ 100’ 122’ 140’ 158’ 173’ 187’ 200’ Range (ft)
Restaurants (100ft2/Person) Assembly Halls (50ft2/Person) Persons BCO Office (108ft2/Person) 120 32 Channel FemtoCell 110 Femto CapacityExample US Office/Hotel (275ft2/Person) Manufacturing (750ft2/Person) 100 90 80 • 25,000ft Office Floor • 1x 32 CE or 2x 16 CE 70 60 Warehouse (1500ft2/Person) • 50,000ft Warehouse • 1x 8 CE 16 Channel FemtoCell 50 40 • 5,000 ft Professional Office (Industrial unit) • 1x 8 CE Large Whse (3000ft2/Person) 30 8 Channel FemtoCell 20 • Manufacturing Plant • 1x 32 CE 10 4 Channel FemtoCell 10 0 Area (ft2) 10k 20k 30k 40k 50k 60k 70k 80k 70’ 100’ 122’ 140’ 158’ 173’ 187’ 200’ Range (ft)
Restaurants (100ft2/Person) Assembly Halls (50ft2/Person) Persons BCO Office (108ft2/Person) 120 Manufacturing (750ft2/Person) 110 Overlay Femto Capacity US Office/Hotel (275ft2/Person) 16 Channel FemtoCell 100 90 80 • Light Use Model • Users: 50% • Load: 200mE • GOS: 2% • N=4: 10 users • N=8: 36 users • N=16: 98 users • N=32: 196 users 70 60 Warehouse (1500ft2/Person) 50 40 8 Channel FemtoCell Large Whse (3000ft2/Person) 30 20 4 Channel FemtoCell 10 10 0 Area (ft2) 10k 20k 30k 40k 50k 60k 70k 80k 70’ 100’ 122’ 140’ 158’ 173’ 187’ 200’ Range (ft)
Special Large Area Applications • Unique large venue applications now receiving significant attention • Large public spaces – Halls; Institutions; Dense public spaces • Use in lieu of pico cells to resolve macro network problems • Temporary venues – Instead of COW • Rural basic services applications • Mountain top valley coverage • Capacity of 32 or more channels, plus data requirements • Higher RF power • Manual configuration override options
1: Coverage/Density Requirements • Multiple Capacity Enterprise Models Required • Approx 8 channel for small enterprises & industrial units • Approx 16 channel for mid size enterprises & lower penetration models • Approx 32 channel for large enterprises & large venues • Approx 32+ for special applications and large public spaces • Coverage aligned with density requirements • Sufficient RF power to support required capacity • Sufficient RF power to provide required coverage • New coverage models for enterprise applications • Including multi-floor cases • Potential WG2 Work Item
RF Power Issues • Support For Increased Capacity • Additional power to support additional bearer channels • Minimum Indoor Coverage • Sufficient to support applicable density model • Enhanced Power Setting Algorithms • Required to manage increased potential for interference • Clustering adds to the complexity • More local intelligence (decentralized) to deal with complexity issues • Additional Coverage Area Cases • Large venue coverage • Outdoor coverage
Restaurants (100ft2/Person) Assembly Halls (50ft2/Person) Persons BCO Office (108ft2/Person) 120 110 DetermineRF Coverage US Office/Hotel (275ft2/Person) Manufacturing (750ft2/Person) 100 Coverage Limit Based On Venue Type 90 80 70 Typical Office Floor “Large Venue” Warehouse (1500ft2/Person) 60 Range vs Power for typical venues 50 Range @ X mW 40 Large Whse (3000ft2/Person) 30 Range @ Y mW Typical Home 20 10 10 0 Area (ft2) 10k 20k 30k 40k 50k 60k 70k 80k 70’ 100’ 122’ 140’ 158’ 173’ 187’ 200’ Range (ft)
II: Power Requirements • Power requirements for enterprise cases • Examine coverage/density cases • Consider greater interference case • Potential WG2 Work Item • Advanced decentralized power setting mechanisms • Account for the more complex clustering cases • Potential WG2 Work Item OR no FF position (vendor specific) • O&M MO enhancements • Support for more decentralized power setting capability • Support for cluster configurations
Mobility & Clustering • A) Single FAP Case - Meets Coverage Requirements • Same as consumer femtocell: Same hand-in/out cases apply • B) Multiple FAP Case - Needed to Meet Coverage or Capacity Requirements • Requires “Clustering” Concept • Multiple FAP units serving a larger contiguous coverage area • Mobility is required within the cluster area • Implies the need for inter FAP handoff • Soft handoff is essential: • Mobility; Capacity gains; Noise reduction • Also helps deal with spike induced ping ponging • Ability to treat cluster as a single location area • Avoid excessive re-registration burden (battery life) • Provide paging economies • Entry/Exit (Hand-in/out) • Hand-in/out to/from any unit within the cluster • Portal issues may concentrate hand-in/out loading • Building Entrance or Lobby • Shared information between units • Hand-in/out restrictions: eg Upper level floors Cluster Mobility Cluster Mobility FAP Cluster
Cluster Topology Options • Each FAP requires access to core and to cluster peers • Three basic topology models may be applicable: • Centralized topology: Central control unit with single large tunnel to core • Master-Slave topology: Designated master unit with tunnel to core, links to peers • Decentralized topology: Each unit independent with peer to peer connections • Preference for a single SKU to reduce sales complexity • Local tools for configuration of inter-femto connectivity and security Centralized Model Master-Slave Model Decentralized Model Advantage: Common connection point Disadvantage: Two product SKUs Advantage: Single product SKU Disadvantage: Unbalanced load Advantage: Single product SKU Disadvantage: Core network aware
User Groups • Closed User Group • Same as consumer femtocell case • White list; Emergency call override • Virtual Closed User Group • May span multiple non-contiguous locations • Includes virtual group services • Open Access • Unrestricted access by valid users & roamers • Applies mainly to public venue implementations • Hybrid Access • Predominately a closed user group • “Visitor” access at certain locations • Lobby areas; Conference rooms • Administration • Greater need for list administration locally/corporately • Administration interfaces (local and possibly remote) FAP Cluster
Virtual User Group Features • Common services in a virtual user group • Short code dialing & intercom • Common white list • Operator adjustments as need • Multi-Site (Multi-FAP) Implementation • May span multiple non-contiguous locations using different FAP • Treat users as part of a single virtual user group • Remote offices, multi-building applications • External network users • Access to user group features from macro network • Features managed by core network • Access to user group features from other networks • Features may be constrained by security concerns Multiple Sites Act As A Single Virtual System Cluster Mobility FAP Cluster
Basic Service Parity • Basic Call Services Parity (Varies by operator) • Originations; Terminations • SMS • Data • Call features • Comparable to consumer Femto Case • Services not required on FemtoCell • Prioritization of macro network services – Some compromises may be needed • Compare to consumer Femto Case • Regulatory Related Capabilities (See Section VII) • Mandatory support for: • Emergency call • CALEA/Legal Intercept • Performance Requirements • Delay tolerance; Blocking • Compared to consumer Femto Case
III: Mobility/Clustering Requirements • Clustering of femtocells to form a single service area • Support for: • Soft handoffs, hard handoffs, hand-in/outs with restricttions • Shared registration and paging information; Accommodate portal issues • Impact of handoffs on capacity & coverage; Potential WG2 work item • Preference for master-slave or decentralized cluster topology • Only one product SKU needed for these configurations • User group support • Support closed, open and hybrid cases • Virtual user group support across physical locations (core network impacts) • Local O&M administration support • Local administrator access for user group maintenance • Service Parity for basic services • Includes basic call functions; Subject to operator refinement/prioritization
Substitution Model • Femto network provides substitute for local wire services • Mobiles take a greater share of call traffic • Remaining local wired sets connected to FAP or FAP system locally (if applicable) • Separate or integrated core network systems • Variations: • SIP phone connection • Analogue phone connection • Competitive to wireline, therefore may not apply to integrated operators • More suited to SOHO and SME applications Premise Boundary To Femto Core Network
Hosted PBX Services Model • Services integration with core network • Mobility & Fixed services integrated/converged at the core • No local connections between equipment on site • May or may not include local IP-PBX equipment (depends on implementation) • Integrated/Converged Services • PBX services integrated with mobility services • Virtual user group features over local and wide area networks • Applies to integrated operators or wireless operators with aspirations Premise Boundary Mobility Core Network Converged Service Functions Hosted PBX Core Network Optional Router/controller
Local Data Interconnect • Local Bypass Operation (LBO/LIPA) • Local LAN data connection outside secured tunnel • Allows mobiles to access local data servers, printers… • No impact on Femto voice services • Remote Break In (RBI/RIPA) • Wide area macro mobiles can access LAN via Femto • Allows private access to data network while roaming • Security Issues • Secured access to LAN from both local and remote mobiles Premise Boundary To Femto Core Network Enterprise Servers To Wire Network IP-PBX
Local Data Interconnect Cases • Local Mobile to LAN Servers • Local Breakout (LBO) via local IP connection • Outside E-FAP security tunnel • Access by customer LAN policy 50 Core (Data) Internet • Local Mobile to Internet (Direct) • Via wireless data core network • Conventional E-FAP & wireless data core network operation 52 51 • Local Mobile to Internet (LBO) • Local Breakout (LBO) via local IP connection • Outside E-FAP security tunnel • Access by customer firewall & policy • Requires criteria to differentiate from (51) GW/ IWF LAN 51 52 50 56 53 54 55 55 56 54 53 • Wide Area Mobile to LAN Servers (via Internet) • Via data core & customer remote access security system • Conventional wireless data core network operation Servers E-FAP • Wide Area Mobile to Internet • Via wireless data core network • Conventional wireless data core network operation • Wide Area Mobile to LAN Servers • Remote Break In via local E-FAP IP connection • Outside E-FAP security tunnel; Customer security/policy • Requires mobile criteria to differentiate from (53) • Wide Area Mobile to Internet (via LAN) • Remote Break In via local E-FAP IP connection • Outside E-FAP security tunnel; Customer security/policy • Requires mobile criteria to differentiate from (54)
Local PBX Interconnect • Local physical connection between FAP system and PABX • Converged services across wireless & wired users • Voice Call Scenarios • Over 20 identified; At least 10 required FAP<>PBX interconnection • Local FAP<>PBX calling & call transfer • Outbound call forwarding & transfer across FAP<>PBX • Inbound call forwarding & transfer across FAP<>PBX • Requires local transcoding for media routing • Enhanced O&M capability to manage interconnection • Local administration of interconnection To Femto Core Network Alternate To Wire Network PBX
Mobile Origination Cases • Mobile to Wide Area Mobile • Via wireless MSC • Conventional FAP operation 1 1 Core (MSC) PSTN • Mobile to General Land Phone (Direct) • Via wireless MSC • Land phone not on PBX • Conventional FAP operation 2 2 • Mobile to General Land Phone (via E-FAP) • Via PBX to PSTN • Wireless bypass operation • Requires criteria to differentiate from (2) • Wireless carrier may not permit this GW/ IWF PBX 5 3 SIP Agent • Mobile to PBX Phone • Via local PBX connection • Additional features can include: • Short code dialing; Intercom; Hot lines E-FAP 4 6 • Mobile to Local Mobile • Via wireless MSC • Conventional FAP operation 5 3 6 4 • Local Mobile to Mobile • Via FAP without core network • Additional features can include: • Short code dialing; Intercom; Hot lines
PBX Phone Origination Cases • PBX Phone to General Land Phone • Via wireline PSTN • Conventional PBX operation 14 10 Core (MSC) PSTN • PBX Phone to Wide Area or Local Mobile • Via wireline PSTN & wireless MSC • Conventional PBX operation 13 11 • PBX Phone to Land Phone • Via PBX and E-FAP to wireless MSC • Wireline bypass operation • Requires criteria to differentiate from (11) GW/ IWF PBX 15 12 • PBX Phone to Wide Area Mobile • Via PBX and E-FAP to wireless MSC • Requires criteria to differentiate from (11) SIP Agent E-FAP 13 12 • PBX Phone to Local Mobile • Via PBX and E-FAP • Additional features can include: • Short code dialing; Intercom; Hot lines 14 15 10 11 • PBX Phone to Local PBX Phone • Via local PBX • Conventional PBX operation
Wireless Network Origination Cases • Wireless Network to Local Mobile • Via wireless MSC • Conventional FAP operation 25 20 Core (MSC) PSTN • Wireless Network to Local PBX Phone (FAP CF) • Via E-FAP and PBX • Mobile is present at E-FAP • Wireless DN call forward to PBX Phone 20 21 • Wireless Network to Local PBX Phone (MSC CF) • Via E-FAP and PBX • Mobile is not present at E-FAP • Wireless DN call forwarded to PBX Phone GW/ IWF PBX 23 22 • Wireless Network to Local PBX Phone • Via PSTN • Wireline DN call forwarded to PSTN • Conventional wireless MSC operation SIP Agent E-FAP 21 23 • Wireless Network to Local PBX Phone (Bypass) • Via E-FAP and PBX • Wireline DN call forwarded to E-FAP • Requires criteria to differentiate from (23) 22 24 24 25 • Wireless Network to Wide Area Mobile • Via wireless MSC • Conventional wireless MSC operation
Wireline Network Origination Cases • PSTN Network to Local PBX Phone • Via PBX • Conventional PBX operation 30 Core (MSC) PSTN • PSTN Network to Local Mobile • Via PBX and E-FAP • Wireline DN call forward to Mobile • Mobile is present at E-FAP 33 31 • PSTN Network to Wide Area Mobile (PBX CF) • Via PBX • Wireline DN call forwarded to Mobile at PBX • Mobile is not present at E-FAP • Conventional PBX operation GW/ IWF PBX 31 32 SIP Agent E-FAP • PSTN Network to Wide Area Mobile (E-FAP CF) • Via PBX and E-FAP to wireless MSC • Wireline DN call forwarded to Mobile at PBX • Mobile is not present at E-FAP • Requires Criteria to differentiate from (32) 32 33 30 34 34 • PSTN Network to Wide Areal Mobile (PSTN CF) • Via PSTN • Wireline DN call forwarded to Mobile • Network based CF implementation
Call Transfer Cases (E-FAP & PBX) • Transfer Call: PBX Phone to Local Mobile • Via PBX and E-FAP • Initiated by PBX; Supported by E-FAP 40 Core (MSC) PSTN • Transfer Call: PBX Phone to Wide Area Mobile • Via PBX and PSTN to wireless MSC • Initiated by PBX (call transfer) • Conventional PBX operation 41 • Transfer Call: PBX Phone to Wide Area Mobile • Via PBX and E-FAP to wireless MSC • Initiated by PBX; Supported by E-FAP • Requires criteria to differentiate from (41) GW/ IWF PBX 43 45 44 40 41 42 42 • Transfer Call: Local Mobile to Local PBX Phone • Via E-FAP and PBX • Initiated by E-FAP; Supported by PBX SIP Agent E-FAP 43 • Transfer Call: Wide Area Mobile to Local PBX • Via MSC and PSTN to PBX • Initiated by wireless MSC (call transfer) • Conventional wireless MSC operation 45 44 • Transfer Call: Wide Area Mobile to Local PBX • Via MSC and E-FAP to PBX • Initiated by wireless MSC; Supported by E-FAP
Local PBX Interconnection • SIP over IP connection preferred • Increasing prevalence of IP based PBX; Rapidly displacing analogue systems everywhere • SIP agents already exist in Femto (CDMA) • Functional Requirements • Interworking function • Ability to anchor and transfer calls where needed • Local transcoding capability required, most likely in the FAP • Security Issues • Secured interconnection required • Some capabilities may be restricted by operator or regulator • Standardization Desirable • Are wireless focused 3GPP and 3GPP2 the right places?? • Like O&M, perhaps seek a more qualified SDO - Discuss
IV: Local Interconnect Requirements • Local Wire Phone Support • Analog or SIP support for substitution model • Hosted PBX Services Support • Compatibility with core network services integration models • Local LAN Data Support • Local Beak-out (LBO/LIPA) • Remote Break-in (RBI/RIPA) • Local PBX Interconnect Support • SIP based interconnection to PBX with support for call scenarios • Security considerations • Desirable to define industry PBX interconnect standard • Potential WG3 Work Item • O&M Support • Administration of local phone connections & LAN interconnections • Configuration & administration of local PBX connections
LAN Interconnection • Connection to local LAN • Ethernet preferred connection method - via RJ-45 • Leverage existing Cat 5/6 wiring plant • 10/100 or Gig-E; RJ-45 physical connection • Support for layer 2 priority (802.1p) • Support for local inter-femto communications • IT connection override capabilities • Local IT administration requires control over certain network parameters • Fixed IP addresses; Firewall & NAT settings; priority flags/levels • Provide a suitable local administration interface • Enhanced O&M to permit local overrides • Restricted interface to prevent access to RF and other parameters • Critical for femto operational security • Cluster connectivity • Support for multiple connections to other cluster FAP To Core
Power Source • Each FAP requires power source for normal operation • Local power source model • Connection to power source local to actual FAP • Assumes local power available or installed for the purpose • Could also apply to non-AC solutions (special ship/aircraft applications) • Central/Remote power source model • Conditioned power supplied centrally via direct connection to FAP unit • Includes PoE implementations and dedicated wiring implementations (current loops) • Power limitations may apply, depending on methods implemented • EC power consumption recommendations • Solar powered outdoor cases Local Power Model Remote Power Model PoE Loop Energizer
Physical Mounting Issues • Multiple mounting implementations needed • Surface mounting: Wall & Ceiling surfaces • Flush/Hidden mounting • In-wall or suspended ceiling flush mount • Bracket mounts (multiple styles) • Fabricated brackets – beams/poles, suspended, rugged • Rack mounting • Service closets; Equipment racks • Antenna Types • Internal or external to provide flexibility • Support for hidden and closet mounted FAP units
V: Physical & Electrical Requirements • LAN • 10/100 or Gig-E Ethernet, RJ-45 • Cluster communications support • Local O&M access for IT related configuration • Security & access restriction for other parameters • Power • Local power model • Remote power model (PoE or current loop) • Low energy consumption to support PoE and for large venue solar power cases • Physical Mounting Requirements • Flexible mounting packaging to cover multiple cases • Surface; Flush; Bracket; Rack; Outdoor options • Antennas • External antenna option to support mounting flexibility
Enterprise O&M Differences • Larger configuration files • User lists and other provisioning information is greater • Advanced RF auto configuration functions • Higher power and more interference potential requires different algorithms • Greater reliance on decentralized measurement and setting algorithms • Support required for clustering • Detection and configuration, including handoff contour estimations • Inter-FAP communications configuration and shared user lists • IT/LAN override support with local administration • PBX interconnection support and local administration • Scaling • Likely to be a smaller number of Enterprise FAP than consumer FAP • It is reasonable to suggest a large scale consumer optimized O&M system will not provide adequate support for Enterprise implementations in any but the smallest single FAP implementations
O&M Models: Common vs Separate • More than one model can be considered to support Enterprise • Single O&M model • Leverage similar provisioning, auto-configuration, location verification mechanisms • Difficult to support the additional requirements for a small subset of managed FAP • Separate O&M model • Provides enterprise specific support for the smaller number of enterprise FAP • Undesirable for many operators since dual IT network interfaces required • Shared ACS model: Best of both previous models • Leverages a common ACS system to managed all downloads • Dedicated enterprise application to support the enterprise FAP functions Single O&M Model Separate O&M Model Shared ACS O&M Model IT Interfaces IT Interfaces IT Interfaces IT Interfaces Combined Femto Appln Enterprise Femto Appln Consumer Femto Appln Enterprise Femto Appln Consumer Femto Appln TR-069 ACS TR-069 ACS TR-069 ACS TR-069 ACS
Shared ACS Implementation • Managed object model to support multiple management applications • Shared MO requires adequate definition to support both consumer & enterprise • Enterprise functions can be a superset of consumer functions • Consumer only uses the basic subset parameters • No impact, if the MO changes are made expeditiously • Requires superset to be added to TR-196 • ACS platform & TR-069 architecture • TR-069 inherently supports multiple applications • Multi-vendor FAP applications • Most ACS systems architected to support multiple applications running on a common ACS • Operational benefits • Separation of support teams and training specific to high value enterprise customers • Development of custom features without impacting mass market consumer base or appln • Single shared ACS complex lowers support costs
VI: O&M Requirements • Extension of MO to support enterprise requirements • Essential regardless of O&M implementation • Includes accommodation of advanced decentralized configuration • Use of vendor specific extensions to provide flexibility • Potential WG3 work item; Define quickly to reduce impacts on deployed systems • Advanced decentralized auto configuration algorithms • Support for clustering & advanced enterprise power setting algorithms • Potential WG2 work item • Local configuration overrides • Support local local IT/LAN administration user interfaces • Open ACS practices or standards • Potential WG3 work item
Regulatory Requirements • Legal Intercept • Local breakout (LBO/LIPA) issues for certain jurisdictions • Remote breakin (RBI/RIPA) issues for certain jurisdictions • New issues regarding interconnection to PBX • Potential WG4 Work Item • Emergency Call (E911; E119) • New issues regarding emergency call routing when interconnected to PBX • Potential WG4 Work Item
Next Steps • Additional operator inputs • 3GPP2 outputs • Provide in support of 3GPP2 activities (3GPP2 SIG Work Item) • 3GPP outputs • Provide in support of 3GPP activities (Potential WG3 Work Item) • WiMAX Forum outputs • Provide in support of 3GPP activities (Potential WG3 Work Item • Creation of potential work items for WG2/WG3/WG4
Potential Work Item Summary • WG2 • Coverage models for enterprise applications • Power requirements for enterprise applications • Impact of handoffs on coverage and capacity • Advanced decentralized power management for clustering cases (optional) • WG3 • Local PBX interconnection interface • O&M managed object extensions to support enterprise requirements • Open ACS requirements or standards, where applicable • WG4 • Legal Intercept issues for break-out/in cases and for PBX interconnect cases • Emergency call issues for break-out/in cases and for PBX interconnect cases