1 / 50

Enterprise FemtoCell Requirements (V0.4)

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.

thyra
Download Presentation

Enterprise FemtoCell Requirements (V0.4)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

  2. 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

  3. 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

  4. I Coverage & Density

  5. 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

  6. Back Up: User Densities Source Data British Council For Offices EPA BASE Study Seattle Energy Codes Portland-Vancouver Planning Dept

  7. 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)

  8. 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)

  9. 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)

  10. 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)

  11. 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

  12. 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

  13. II RF Power

  14. 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

  15. 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)

  16. 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

  17. III Services: Mobility; Clustering; User Groups

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

  24. IV PBX/LAN Interconnect

  25. 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

  26. 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

  27. 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

  28. 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)

  29. 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

  30. 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

  31. 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

  32. 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

  33. 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

  34. 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

  35. 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

  36. 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

  37. V Physical & Electrical Attributes

  38. 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

  39. 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

  40. 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

  41. 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

  42. VI O&M Issues

  43. 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

  44. 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

  45. 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

  46. 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

  47. VII Regulatory Issues

  48. 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

  49. 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

  50. 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

More Related