1 / 13

TVWS Architecture for SDD

TVWS Architecture for SDD. Date: 2010-02-25. Authors:.

Download Presentation

TVWS Architecture for SDD

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. TVWS Architecture for SDD Date: 2010-02-25 Authors: Notice:This document has been prepared to assist IEEE 802.19. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Joe Kwak (InterDigital)

  2. Overview • This paper describes a simple architecture for the 802.19 system • Entities, interfaces and system boundary are well detailed • Major functions of entities are listed. • Observations to be noted from architecture and interfaces are listed. • Level of detail in notes is provided for understanding only, NOT as proposal for SDD. • Conclusions are provided at the end of the document. Joe Kwak (InterDigital)

  3. FCC R&O has Defined TVWS Device Types NOTE: It is likely that most Mode I and Mode II devices will operate as Sensing Only devices when they are unable to establish an Internet connection or connection to a Master enabling device. Slide 3 Joe Kwak (InterDigital)

  4. Rationale for SDD Architecture Providing Internet-based services to WSDs to facilitate use of TVWS is inevitable. The FCC has paved the way by authorizing internet based Service Providers (SPs) to provide access to FCC dbase for channel clearance. Other regulatory bodies worldwide are expected to follow the lead of the FCC to provide controlled access to TVWS using an internet accessible database. The simple architecture presented here is based on a high-level view of coexistence services designed to complement the architecture defined by the FCC. The entities used in this architecture may be combined with other entities or split to define multiple alternative but similar architectures; alternative may and should be considered during the proposal phase of this project. Slide 4 Joe Kwak (InterDigital)

  5. Proposed Architecture • The system architecture includes • 3 Entities • Coexistence Server (CS) • Coexistence Client (CC) • Optional Coexistence Spectrum Manager (SM) • 6 Interfaces: A: External from Coexistence Server to WSDbase SP and A* to TVBDs without Coexistence Client (A and A* are different sides of same interface) B: Internal from Coexistence Server to Coexistence Client C: Internal from Coexistence Server to neighbor Coexistence Server D: Internal from Coexistence Server to Spectrum Manager E: Internal from Spectrum Manager to other Spectrum Manger F: External from Spectrum Manager to Network Operator • The System boundary is well defined in the figure. Slide 5 Joe Kwak (InterDigital)

  6. Proposed Coexistence Architecture Coexistence Server Coexist Dbase Assisted AP TVBD: 802.19 entity: Coexist Client Coexist Client Coexist Client RF Connection: Fixed/ Mode II RAT y SOs adhocs RAT y Fixed/ Mode II RAT y 802.19 Interface: WSDbaseGroup Service Provider Network Operator(s) X FCC Dbase Unassisted TVBD: F A 802.19 System E (sync to others) Coexistence Spectrum Manager (optional) Fixed/ Mode II RAT z Fixed/ Mode II RAT z Interface Assisted TVBD: D* D C Mode I RAT z (sync to others) B A* SOs adhocs RAT x Fixed/ Mode II RAT z Fixed/ Mode II RAT z PHY Y SOs adhocs RAT z PHY Z Fixed/ Mode II RAT y Mode I RAT y Mode I RAT y Mode I RAT z Mode I RAT z Mode I RAT y Slide 6 Joe Kwak (InterDigital)

  7. Notes on Architecture Coexistence Client is located in Mode II devices Mode II devices without Coexistence Client may (SHOULD) obtain access to WSDbase SP by using Coexistence Server as proxy and will benefit from coexistence services. Mode II devices without Coexistence Client which access WSDbase SP directly will not benefit from coexistence services. SDD architecture serves CCs in AP TVBDs (i.e. devices which act as connection portals to internet) and also CCs in mesh network topologies. Mode II devices with Coexistence Client but without internet connection operate as Sensing Only devices and are not part of the SDD architecture. SDD architecture does not serve Sensing Only devices Slide 7 Joe Kwak (InterDigital)

  8. Coexistence Server Functions • Provides an array of coexistence services for CCs: • Discovery of available TVWS channels considering FCC incumbents and current neighbor TVBDs • Discovery of neighbor TVBDs, their locations, IP addresses, channel, and other PHY parameters • Communication with neighbor TVBDs, with protocol or tunneling. • Negotiation with neighbor TVBDs for channel sharing • Coexistence advice for channel access and channel sharing • Coexstence commands for channel access and channel sharing • Others? • Collects locations, IP addresses and PHY parameters from all assisted TVBDs in geo domain and stores in Dbase • Requests and collects measurement and sensing data from all CCs in geo domain and stores in Dbase • Provides information to/from the dbase for CCs and Spectrum Manager Slide 8 Joe Kwak (InterDigital)

  9. Coexistence Client Functions Is an embedded SW application within an assisted TVBD Type II device, consistent with Nokia view in 19/0013r0. Always connects to CS if ANY internet connection is available Is dormant in Sensing Only devices when no internet is available. Provides discovery of neighbor TVBDs when requested. Provides communication with neighbor TVBDs via CS when requested. Provides communication from device to CS to access coexistence services. Responds to measurement requests (sensing, channel traffic load, served device traffic load, link SNR, etc) from CS, initiates device measurements, and provides measurement results to CS. Slide 9 Joe Kwak (InterDigital)

  10. Spectrum Manager Functions Distributes network operator spectrum policy for all coexisting networks across all geo domains. Provides spectrum assignments (coexistence commands) for centrally controlled CCs Provides spectrum advice (coexistence alternatives) for network assisted CCs or distributed control CCs. Accesses all information in dbases of all CSs for improved spectrum advice or assignments. Updates and stores Client and TVBD context (location, PHY params, traffic stats, etc.) on a network by network basis. Negotiates channel sharing between Clients when requested. Slide 10 Joe Kwak (InterDigital)

  11. Notes on Interfaces and Implementations All interfaces defined here are internet IP interfaces which will support separately located system entities. Since all interfaces are internet based, security is of utmost importance. If entities are collocated, interfaces in implementations may be simplified or eliminated. Messages and protocols to be defined for each interface depend on location of detailed sub functions which are not defined here. Functions and sub functions may be relocated from one entity to another based on trade studies supporting such relocation. For distributed control networks implementing a minimalist architecture, the Spectrum Manager is not present and the only services provided by the CS are discovery and communication. For minimalist implementation there are only 2 entities (CS and CC) and only 3 interfaces (A, B, and C). Slide 11 Joe Kwak (InterDigital)

  12. Summary and Conclusions • This simple architecture provides a range of coexistence services and a range of implementation options to meet the varying needs of TVWS networks now and into the future. • The described architecture is comprehensive and includes the concepts described in alternative architecture proposals: • 19-10/0019r0 from Nokia • 19-10/0020r0 from NICT • Using an optional Spectrum Manager provides architectural flexibility to address the minimalist needs of simple distributed control networks while providing for the needs of the centrally managed and controlled networks. • Contrary to claim on page 9 of 19-10/0019r0, a minimalist system for distributed control networks WILL REQUIRE a network based entity and service for discovery and internet communication between neighboring TVBDs and collocated heterogeneous networks. • This architecture is as simple as possible and can flexibly adapt to the varying needs of the diverse networks which will use the TVWS. • This is only a "vision" architecture for the SDD. Any alternatives should be considered and evaluated against this SDD architecture in the proposal evaluation process. Slide 12 Joe Kwak (InterDigital)

  13. Questions & Discussion Slide 13 Joe Kwak (InterDigital)

More Related