Hybrid Wireless Mesh Networks Requirements Collection for Integration in End to End Architectures Eugen Borcoci, Radu Lupu Telecommunication Dept. University Politehnica of Bucharest Bucharest, Romania
[email protected],
[email protected] aggregation) and not the core IP networks, but is E2E capable, i.e it can be coupled with core IP networks or Internet. Together with technical elements the business entities actors have been considered, as important cooperating in the E2E chain. This paper proposes a systematic framework to collect and structure the system requirements as to respond to the needs of different business actors (network providers/operators, end users, high level services providers, etc.). The paper organisation is the following. Section 2 shortly presents the SMART-Net architecture. The Section 3 exposes the main framework and methodology for a systematic requirements definitions and collection for a complex network and terminals system. The Section 4 applies the methodology to the SMART-Net architecture. The Section 5 presents examples and Section 6 the conclusions and a future work outline.
Abstract— The wireless technologies and specifically multi-hop wireless mesh networks (WMN) based on heterogeneous infrastructures emerged as an important solution for Broadband Wireless Access (BWA). The WMN integration in end to end architecture, especially in the perspective of Future Internet needs a careful definition of system requirements seen from several perspectives. This paper proposes a systematic requirements collection methodology for hybrid WMN architecture, defined in the framework of the FP7 European Project SMART-Net. Keywords - wireless mesh networks, WiMAX, infrastructure, end to end, QoS, network architecture
I.
hybrid
INTRODUCTION
The heterogeneous broadband wireless technologies are more and more used at the edge of the large networks. Except the standard definitions (e.g IEEE 802.x, [1], [2]) oriented mainly on for PHY and MAC layers, extended and flexible architectural end to end (E2E) models are necessary [3], [4], able to support the large variety of functionalities (interoperability, mobility, QoS, E2E multi-domain capabilities, etc.), implementations and future developments and also different needs of higher layer applications and services. AS an example, for IEEE 802.16 technology, the WiMAX Forum [3], [4], extended the framework, by defining the reference models and procedures, including the IEEE 802.16 technology in complete end to end architectures. Definition of complex functional architectures starting from a large set of requirements and then the progress in the specification refinements, together with requirements detailing constitute important phases of the system specification and design. The FP7 ICT European project SMART-Net, [5], [6], [7], has proposed a flexible BWA architecture covering several heterogeneous radio technologies (IEEE 802.11/15/16) and networks, compliant with WiMAX Forum reference model [3], [4] and new emerging standard IEEE 802.11s for mesh networks. The architecture can support multimode wireless mesh networking, smart antennas, multi-RAT mesh operations, and allows resilient and flexible communications between multimode devices. A flexible functional architecture, E2E extensible, has been defined in [7]. The architecture covers only the so called edge networks (access,
c 978-1-4244-6363-3/10/$26.00 2010 IEEE
II.
GENERAL FRAMEWORK FOR REQUIREMENTS COLLECTION
In this section we define the framework for SMART-Net system requirements definitions, while considering general concepts as in [8] – [12]. In the activity of requirements collection, all business actors/stakeholders mentioned in section above has been considered: CC/ICP, CP, BAP, RAP, CSNP, HLSP. A hierarchy of requirements can be defined, based on levels, classes and subclasses in order to structure the sets of different requirements and facilitate analysis/check of their cross consistencies. Assumptions, dependencies and constraints impacting the SMART-Net system have been first evaluated in order to define the environment in which SMART-Net will act and limits of its scope. These have been cross-checked with the requirements list derived from the users and provider’s needs. The SMART-Net requirements are related to basic functional capabilities (broadband data flow connectivity services, fixed/mobile transport, QoS, internetworking and E2E capabilities - in the WMNs) and also to non-functional or performance characteristics such as: scalability, throughput, coverage, availability, reliability/resiliency and security. For requirements collection the following principles have been applied:
379
•
• •
• • •
III.
the limits of the system related to services offered, technologies used and the scope and relationship with its environment. The ADCs may be expressed at several levels: high level – they are resulted from business considerations; low/ technical level: these ones are usually derived from the former (they are expressed as a set of technical issues mappings of the high level ADCs), or can be directly expressed in technical form. The ADCs scope may be: global to a multi-domain environment (Global)- i.e. referring to a larger environment than SMART-net scope. Such assumptions will characterise the environment in which SMART-net system will act; local to “SMART-NET system” (Local_SMART-Net); local to a subsystem of the SMART-net (Local_subsystem). There can be a mapping 1-to-1 or 1-to-many between an ADC statement and a requirement.
the general assumptions/dependencies/constraints related to the project scope and used technologies, have been evaluated, while maintain the initial project objectives. This defines the environment in which the system acts and the borders of its technical subdomains. several levels of the overall system targets are defined, starting from a basics to more advanced versions. all business actors and their roles have been considered. From these actors, some general requirements could arise. They can be expressed at: high level – as originated from business/policies objectives and /or consideration; low level – representing technical requirements, either derived from the former, or directly defined. a taxonomy of requirements has been defined based on types, classes, to allow structuring and facilitate their analysis for cross consistencies. the activity of requirements refinement is advancing in parallel with architecture definition and development with cross feedback between the two activities. distinction should be made made between: requirements imposed on the overall system architecture, which can consist in a larger list to fulfil the objective of an open architecture; a restricted list of requirements (which is a subset of the former list) applied to the first implementation versions.
B. Requirements The SMART-NET system should fulfill a rich set of diverse requirements. By requirements we understand sets of general characteristics requested to be fulfilled by a system or a subsystem. We generally characterize the overall set as “ System Requirements - SysReq”. The inputs to define the system requirements are coming from: general initial ADCs describing the macro capabilities of the system and also defining its limits/scope; end user/scenarios requirements according to specific needs of proposed scenarios for high level services and applications supported by the SMART-Net system; provider/operator requirements – usually derived from its business and technical objectives to allow efficient realization and exploitation of the system. The Fig.1 shows the relationships between entities used to determine the system requirements. The general assumption can influence directly the SysReq. Also the End User Requirements and Provider/operator requirements must take into account the general ADCs as given conditions/restrictions. The End User Requirements and Provider/Operator Requirements specifiy refinements of the assumptions from their point of view and also introduce their specific requirements which will be mapped on SysReq.
SMART-NET SYSTEM REQUIREMENTS COLLECTION METHODOLOGY
This section introduces the process of systematic definition and collection of SMART-Net system requirements. A. Assumptions, Dependencies and Constraints Assumptions: these are factors that are believed/considered to be true during the SMART-Net life cycle. If changed, they may affect negatively the system outcomes. They include, but are not limited to, end-user characteristics, known technology infrastructure, resource availability, and funding availability. Dependencies: some external dependencies exist, that can affect the system requirements specification (SRS). They are outside of project scope and control and must remain true for the system life, to succeed. (e.g. dependency might be that an application relies on a different application to provide specific data). Constraints: these are factors limiting the system scope and functionality, including, but not limited to, regulatory policies, infrastructure limitations, resources, and licensing. Constraints are imposed on the solution by circumstance, force, or compulsion. They limit the options available to a designer of a solution by imposing immovable boundaries and limits. We denote them collectively by acronym ADC. The ADCs are initial - general (predefined) statements derived from both the environment in which the system will work and from the main strategic objectives of the project. They can represent predefined restrictions obtained from SMART-NET scope as initially defined in the Technical Annex. The ADCs establish
C. Taxonomy of requirements This section propose a taxonomy of requirements. There can be two instances in which an entity should deal with such requirements. If the entity is a “provider” then it should fulfill a given set of requirements because: - some ADCs have been already defined upon this entity; - a “customer” requires from the provider to offer certain characteristics of the service. If the entity is a “customer”, then it can ask requirements as a desired set and then request them from a provider. 1) Categories The requirements can be: functional, i.e. related to the correctness which the functions of the system should fulfill (e.g.: algorithms, mechanisms, protocols, horizontal and vertical interfaces, QoS, mobility, internetworking, etc.);
380
General Assumptions, Dependencies, Constraints
Type: End User (scenario) Requirements
Type: Provider/ Operator Requirements
General Requirements
mapping
Determines the requirements at SMART-Net system interfaces
Other networks (Internet)
System Requirements
Customer Premises Equipments
SMART-Net WMN System
Figure 1. General framework for requirements collection
- i.e referring to a larger environment than SMART-net scope. Such requirements will characterise the environment in which SMART-net system will act. They are actually needed and should be fulfilled in order that SMART-Net can smoothly cooperate in end-to-end environment with other systems; local to “SMART-NET system” (Local_SMART-Net); local to a subsystem of the SMART-net (Local_subsystem). 5) Classes The classes do not define disjoint sets of requirements. The class is a “dimension” or a “point of view” on a given requirement. So, the same particular requirement may belong to several classes. We may have: Function class- defining the specific requirements of a functionality or subsystem. It is not strictly related/limited to a given architectural layer. The function class can be for instance split in different sets of functional and non-functional requirements, on: QoS, Security, Mobility, Coverage, Throughput, Accessibility, Resiliency, Availability, Scalability, etc.; Architectural classrelated to the architectural layers set seen as a whole. One can have requirements addressed to: data, control or management planes. On vertical scale, one may have requirements addressed to different layers, from layer one up to application layer.
non-functional – aspects related to flexibility, reliability, availability, scalability, security, traffic capacity , performance metrics, etc. Note that depending on the system role some non-functional requirements can be included in the functional category (e.g a security subsystem has the security functions considered as its main functional requirements). 2) Types Two types are (Fig. 1) corresponding to: End user (scenarios) – expressing the requirements to be met in order to satisfy the high level services scenarios. Here we avoided the more general term “customer” as to emphasize that entities expressing such requirements are external and they are using the services offered by the SMART-Net; Provider/Operator expressing the requirements to be fulfilled by the system in order to satisfy the provider/operator needs which can be specific to the development exploitation and maintenance. 3) Levels Similar as in the assumptions case, the requirements may be expressed at two levels: high level – they are resulted from business considerations; low level or technical level - these ones are usually derived from the former and expressed as a set of technical issues related to the high level assumptions or can be directly expressed in technical form. Example: An ANP – Access (Service) Network Providers (this can be WiMAX- network owner and manager) intends to have its Access Network, not only as an edge of an IP core, but additionally able to operate as an edge of a 3G network. This is rather a business decision, taken by and related to ANP, (it can be also seen as an assumption) but if this is accepted, then specific detailed technical requirements should be derived from it and appropriately refined. 4) Scope Similar to the assumptions case, the requirements may have one of the three scopes: global to a multi-domain environment TABLE I.
IV.
EXAMPLES OF SMART-NET SYSTEM REQUIREMENTS
This section will give samples (out of a large set), of requirements defined/ collected by applying the methodology described in the previous sections to the SMART-net system. The notations introduced in the Section IV are used. The Table 1 presents a partial list of the general ADCs applied to SMART-Net system. Table 2 shows a partial list of the requirements derived from the needs of a Multimedia distribution support service.
EXAMPLES OF GENERAL SMART-NET GENERAL ADCS
GADC.1
Assumption, Dependency, Constraint (C)The SMART-NET scope covers BWA with main focus on smart antennas usage.
Level Business
GADC.2
(A) SMART-Net system supports general
Business
Scope Local_ SMARTNet Local_
381
Description It defines the main area of work for SMART-Net system It defines the high level services supported. A complex
GADC.3
GADC.4
GADC.5 GADC.6 GADC.7
data applications and services including r.t. (video/ audio/ multimedia) with several classes of QoS guarantees. (A/C) The general SMART-Net architecture supports two kinds of scenarios: Connectivity services (BWA and backhaul transport) and High level services scenarios (emergency, public safety and multimedia distribution) (A) SMART-Net will apply a decentralized architectural approach in which the access infrastructure is hierarchically distributed in the network. (A) Local CPE may be responsible for resource management, including QoS, in their respective segments (D)IP QoS technologies used in the CSN will be: DiffServ, MPLS, MPLS+Diffserv (C) SMART-Net architecture will support horizontal micro and macro mobility and also vertical mobility TABLE II.
SMARTNet
application may include several services, e.g (VoIP + video streaming).
Business
Local_ SMARTNet
It defines scenarios for SMART-Net usage. Each high level services scenarios may include several services
Technical
Local_ SMARTNet
It states that the architecture of the SMART_Net will be not fully centralised and several tiers are to be defined.
Technical
Local_ subsystem
Technical
Local_ subsystem
Technical
Local_ SMARTNet
This shows that in the CPE part one may have or not QoS guarantees, depending among others on technologies used (xDSL, WiFI, etc.) This limits the QoS technologies in the core. If cooperating with CSN, the SMART-Net will deliver appropriate mapping of the its QoS parameters to those used in the CSN The micromobility will be solved conforming the L2 capabilities of 802.16 or 802.11 and macromobility will be solved in cooperation with MIPv4 or MIPv6.
EXAMPLES OF REQUIREMENTS FOR MULTIMEDIA CONTENT DELIVERY
ID
Multimedia Content Delivery Requirements; Type: End User
Level
Scope
Class
MCD-Req.1.
VoIP and Videoconference should be supported in point-to-point and multipoint communication Standard figures related to QoS and bandwidth requirements will be defined for applications and should be supported by SMART-NET system The access of an user to SMART-Net system will be checked for authorization
Business
Global
Archit.
Technical
LocalSMARTNet
FunctionQoS
SMART-Net will not deal with rate adaptation at application layer
Technical
LocalSMARTNet Global
FunctionQoS, security FunctionQoS
Two kind of authorizations will be performed: Access authorization; QoS level authorization
LocalSMARTNet
Functionsecurity
MCD-Req.2.
MCD-Req.3. MCD-Req.4. MCD-Req.5.
User can select among several QoS classes, with different levels of guarantees Confidentiality, integrity and privacy are supported at transport level by SMARTNet
V.
Technical technical
CONCLUSIONS
[5]
ACKNOWLEDGMENT This work has been supported by the European Research Project FP7 SMART-NET project No. 223937, 2008-2011. REFERENCES [2] [3] [4]
Subsets will be experimented in testbeds
The call will be rejected by SMART-Net if guarantees are asked for and there are not enough resources in the SMART-Net system L2 and L3 means will be used in the SMART-Net system
SMART-Net Deliverable ID2.1 “Requirements and specifications of SMART-Net targeted scenarios” –January 2009, www.ict-smartnet.eu [6] SMART-Net Deliverable ID2.2 “SMART-Net-based Services Roadmap and SWOT analysis” January 2009, https://www.ict-smartnet.eu [7] SMART-Net Deliverable ID2.4 “Network Architecture and System Specification” October 2009, https://www.ict-smartnet.eu [8] Carlberg, K., Atkinson, R., "General Requirements for Emergency Telecommunications Service", Informational, RFC 3689, Feb 2004. [9] ETSI TR 102 182 V1.1.1 (2006-03), Technical Report, „Emergency Communications (EMTEL); Requirements for communications from authorities/organisations to the citizens during emergencies”, http://www.emtel.etsi.org/ [10] ETSI TR 102 410 V1.1.1 (2007-08), Technical Report, „Emergency Communications (EMTEL); Basis of requirements for communications between individuals and between individuals and authorities whilst emergencies are in progress”, http://www.emtel.etsi.org/ [11] ETSI TR 102 445 V1.1.1 (2006-10), Technical Report, “Emergency Communications (EMTEL);Overview of Emergency Communications Network Resilience and Preparedness”. [12] ETSI TS 102 181 V1.1.1 (2005-12), Technical Specification, “Emergency Communications (EMTEL); Requirements for communication between authorities/ organizations during emergencies”, http://www.emtel.etsi.org/
The paper introduced a systematic methodology to define/collect the system requirements for a complex WMN architecture. The approach taken allows a clear definition and subsequent design of the functional blocks of the SMART-Net system. Such an approach can be as well extended for other instances of networks.
[1]
Remarks
IEEE 802.16e-2005, “Air Interface for Fixed and Mobile Broadband Wireless Access Systems”, www.ieee.org IEEE 802.11-2007 Std. “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications”- 2007, www.ieee.org WiMAX Forum, “Mobile System Profile Release 1.0.Approved Specification,” Rev. 1.4.0: 2007-05-02. WiMAX Forum, “Network Architecture Stage 2 and 3 — Release 1.0 (Revision 1.2)”.
382
