Jamal El Hachem
email: jamal.elhachem@univ-pau.fr

Zi Yang Pang

Vanea Chiprianov
email: vanea.chiprianov@univ-pau.fr

Ali Babar
email: ali.babar@adelaide.edu.au

Philippe Aniorte
email: philippe.aniorte@univ-pau.fr

Model Driven Software Security Architecture of Systems-of-Systems

Keywords: Model Driven Engineering, Model-based Software Engineering, Modeling Language, Software Architecture, Systems-of-Systems Security, Smart Cities, Smart Campus

Recently, there is a growing interest in Systems of Systems (SoS), their architecture, security and application domains. However, their specific characteristics such as the operational independence of SoS constituent systems (CS), the absence of central authority and their emergent behavior make the modeling of their structure, behavior and security a complex task. One of the current main security challenges in the context of SoS is the cascading attack problem. The challenge is to predict the concatenation/sequence of CS's vulnerabilities that could be triggered resulting in destructive cascading failures and take corrective actions to reduce the cost, development time and effect of later changes. In this paper, we propose a domain specific modeling language (DSML) to represent SoS security architecture. Having SoS security models will enable the discovery, analysis and resolution of cascading attacks, in the architecture phase, preventing development time and cost wastage. Following a Model Driven Engineering (MDE) approach, we generate a graphical editor for our DSML and use it to model a Smart Campus case study.

I. INTRODUCTION AND BACKGROUND

We live in a hyper-connected world where software systems become more and more linked. There are estimates that by 2020 thirty one billion intelligent devices will be connected and world wide market for Systems of Systems (SoS) will surpass 6.5 billion euros [START_REF] Pétrissans | Towards SoS trends and challenges[END_REF].

SoS is a promising research field gaining increasing importance. Although there have been several attempts to define SoS, there is yet no standard definition [START_REF] Jaradat | A histogram analysis for SoS[END_REF]. However, one of the popular definitions, which we also use in this paper, is that of Jamshidi [START_REF] Jamshidi | SoS innovations for 21st century[END_REF]: "SoS are large-scale, distributed, concurrent systems comprised of complex systems". These complex systems are systems themselves and in our work we choose to call them Constituent Systems (CS). Many other researchers identified SoS by their distinguished characteristics, particularly Mair specifies the following five essential characteristics: operational independence of the elements, managerial independence of the elements, evolutionary development, emergent behavior and geographic distribution [START_REF] Maier | Architecting principles for SoS[END_REF]. Several other concepts could describe SoS such as: global mission, belonging, autonomy, connectivity, diversity [START_REF] Gonçalves | Towards a conceptual model for software-intensive SoS[END_REF].

These characteristics impact SoS non functional properties as well, specially security, on which we will focus in this paper. Security has been identified as a critical SoS research theme [START_REF] Dogan | Economic and societal significance of the sos research agenda[END_REF]. In fact, SoS suffers from complex systems security problems, as well as additional problems raising from their specific characteristics as shown in [START_REF] Hachem | Towards Model Driven Architecture and analysis of SoS access control[END_REF] [START_REF] Chiprianov | Challenges in security engineering of SoS[END_REF].

One of the crucial SoS-specific security problems is the cascading attacks. An attack, as defined by ISO IEC 27000 [START_REF]Information technology -Security techniques -Information security management systems -Overview and vocabulary[END_REF], "is any unauthorized attempt to access, use, alter, expose, steal, disable, or destroy an asset". Considering that:

1) It is rare that an attacker exploits a single vulnerability on a single target system to achieve its objective, in most cases he uses several single attacks on several systems to accomplish his attack [START_REF] Gallon | Cvss attack graphs[END_REF]. 2) "The consequences of attacks on the SoS cannot be understood by means of the merely evaluation of the behavior of the single systems, but require an assessment of the effect of the inter-dependencies on the behavior of the whole SoS" [START_REF] Guariniello | Communications, information, and cyber security in SoS: Assessing the impact of attacks through interdependency analysis[END_REF]. We define a cascading attack as a succession of possible single attacks or a sequence of exploited vulnerabilities resulting from the CS inter-dependencies employed for the achievement of the SoS global goal.

These cascading vulnerabilities may serve, intentionally or unintentionally, to compose a cascading attack that affects the whole SoS and cause huge important damages. The stuxnet attack [START_REF] Nerc | Sql slammer worm lessons learned for consideration by the electricity sector[END_REF] is one of the most well-known cascading attack. It was based on a 500 kilobyte computer warm that attacked in three phases: first it targeted Microsoft Windows machines and networks, repeatedly replicating itself, finally it compromised the programmable logic controllers. Starting from a system via a USB stick, stuxnet infected 14 industrial sites in Iran, including an Uranium-enrichment plant. Recently, FireEye researchers have discovered a complex malware which uses some elements from stuxnet 1 .

However, addressing this problem involves studying how to model SoS structure and behavior, focusing on their security aspects. Furthermore, knowing that early discovered vulnerabilities are less expensive to fix than those discovered later [START_REF] Austin | A comparison of the efficiency and effectiveness of vulnerability discovery techniques[END_REF], how could security vulnerabilities be modeled within SoS software architecture to allow the prediction, at an early stage, of their concatenation/sequence which could be triggered in an unknown way and result in a cascading attack?

In this paper, we propose a Domain Specific Modeling Language (DSML) called SoSSec: Systems-of-Systems Security, with its corresponding graphical editor. We adopt the Model Driven Engineering (MDE) approach to define our DSML which will be used to model SoS security architectures.

MDE is considered as an effective approach to address significant challenges in SoS architectures modeling [START_REF] Nakagawa | The state of the art and future perspectives in SoS software architecture[END_REF]. In MDE, models can be expressed using different languages like General Purpose Modeling Languages (GPML) or DSML. The main advantage of a DSML is its ability to simplify the modeling of complex systems by offering expressive domain specific abstractions and notations focusing on a particular problem domain in a precise and concise way. The use of a DSML to model non-functional properties, like security, lead to better solutions [START_REF] Baker | Model-Driven Engineering in a large industrial context -motorola case study[END_REF]. In our case, the DSML will be dedicated for SoS cascading security attacks modeling. However, since it is very costly to define a new language from scratch, our DSML is defined as an extension of the System Modeling Language (SysML). SysML is a general-purpose graphical modeling language for specifying, analyzing, designing, and verifying complex systems. One of the main advantages of adopting an extension mechanism, is that the reference language is refined in a strictly additive manner preventing the contradiction of the standard semantics.

Generally, the definition of a DSML consists of three essential components [START_REF] Kurtev | Model-based DSL frameworks[END_REF]: -Abstract syntax: set of concepts and relations that serve to express a model. It is usually described using a MetaModel; -Concrete syntax: set of symbols to represent the MetaModel; -Semantics: to determine the meaning of the models, usually expressed by simulation or code generation. Once the concrete syntax of the DSML is defined, MDE allow the (semi)automatic generation of its tools, such as the graphical editor modeling tool and the simulation tool.

After defining the SoSSec MetaModel (abstract syntax) and developing its graphical editor (concrete syntax), we use it to model a Smart Campus SoS case study.

The remainder of this paper is organized as follow: Section 2 briefly introduces the MDE approach for DSML definition. In Section 3 we discuss related work. Section 4 presents our SoSSec DSML and its tools. Smart Campus SoS security models are presented in Section 5 while Section 6 concludes the paper.

II. STATE OF THE ART

Historically, many approaches were used to model and analyze software architectures of a system, like: formal approaches which incorporate mathematical analysis in the software architecture models; goal oriented approaches which focus on goals to capture the functional and non functional system requirements in the software architecture models; and Architectural Description Languages (ADLs) which are languages used to describe system software architecture, like its components, connectors, rules and guidelines.

In trying to choose between these broad types of approaches, we focused on analyzing their suitability for modeling SoS specific characteristics, as identified by Mair [START_REF] Maier | Architecting principles for SoS[END_REF]. Some formal methods (e.g. graph based-methods: Bayesian Networks (BN), Functional Dependency Network Analysis (FDNA) seem well suited to model the geographic distribution and interactions between CS but they are still limited compared to ADLs regarding the representation of the structural architecture (like components; interfaces; contracts and ability to describe hierarchical levels of details).

Goal oriented approaches such as Multi-Agent Systems (MAS) could be used to model SoS global goal and CSs individual goals, as well as behavioral aspects like the emergence and the interaction between different CSs. However, like in the case of formal methods, goal oriented approaches are not the best suited for describing SoS structural architecture. Besides, seeing that another crucial aspect in the context of our work is the ability to model security mechanisms, properties and concepts like vulnerabilities, pre/post conditions and attacks, ADLs security extensions presents more useful modeling concepts than goal oriented approaches.

For these reasons, we choose to build our DSML upon an existing ADL to model SoS taking into account their characteristics and security properties. However additional concepts inspired from goal oriented approaches will be used to describe some SoS concepts like global and individual goals. Furthermore, once the SoS security models are designed, formal methods-inspired approaches could be used to discover possible paths for cascading attacks and analyzing and proposing solutions to tackle them.

A. System of Systems Modeling Approaches

After restraining our state of the art to ADL for modeling SoS structure, behavior and security, we selected the latest and most used approaches adopted in recent International and European SoS projects like COMPASS2 , DANSE3 , Road2SoS 4 . Following we present the analyzed ADLs:

An extension of the Architecture Analysis and Design Language (AADL) was proposed in a recent work [START_REF] Zhang | Applying system of systems engineering approach to build complex cyber physical systems[END_REF] to specify and model cyber-physical systems based on SoS approach.

In [START_REF] Cavalcante | Describing cloud applications architectures[END_REF] the authors propose an extension of Acme to model the architecture of cloud applications by introducing some concepts like relationships between elements, contracts, etc. The proposed ADL remains a simple specific language for cloud SoS service providers and applications. Previously mentioned ADLs lack concepts to model SoS taking into account their special characteristics, and remain specific to particular domains.

Lately, in the COMPASS European project, SysML was used to model SoS CSs, their interfaces and contracts that oversee operations between them. Along with SysML, Compass Modeling Language (CML) was proposed for contract

Goal concept - + + +-(task) - Context concept - - - + - Attack concept - - - - + Security prediction - - +-(goal satisfaction) - -
verification at interfaces [START_REF] Bryans | SysML contracts for SoS[END_REF]. The proposed approach does not take into account yet security features in the contracts. Some recent studies on ADL for software intensive SoS compare UML, SysML, SysML+CML and X-UNITY regarding a number of features to exhibit their ability to model SoS [START_REF] Guessi | Characterizing architecture description languages for Software-Intensive SoS[END_REF] and propose a conceptual model for missions of SoS [START_REF] Silva | On the characterization of missions of SoS[END_REF]. Results show that SysML seems to be the best suited approach for SoS architecture modeling due to its ability to model CS structure and interactions in terms of interfaces and constraints. This study shows that the existing ADLs that have been used recently for describing SoS architectures miss some of the SoS features like: The representation of CS missions (goals) and evolution, architectural elements that manages the interactions (mediators) among CS, the architecture description of SoS emergent behavior resulting from CS interactions related to SoS mission accomplishment.

We can conclude that none of the existing languages can be used as a standalone approach to model SoS taking into account their specific characteristics as well as security properties and specially the cascading attack problem. Despite that, SysML extended with some concepts inspired from [START_REF] Guessi | Characterizing architecture description languages for Software-Intensive SoS[END_REF][21] like mission, global mission and individual mission seems like a strong basis for SoSSec.

B. System Security Modeling Approaches

Generally, security deals with confidentiality, integrity and availability of data [START_REF] Avizienis | Basic concepts and taxonomy of dependable and secure computing[END_REF]. These essential properties, as well as security mechanisms like access control, authorization, encryption need to be described and verified as soon as possible in the development life cycle of any system. This is the more important in the context of SoS as additional security problems may raise. In this work we will focus on the cascading attacks problem. In [START_REF] Hachem | Towards Model Driven Architecture and analysis of SoS access control[END_REF], there have been identified that approaches which handle SoS, architecture and security aspects, all three together are not numerous: [START_REF] Duren | Designing and operating through compromise: Architectural analysis of CKMS for the advanced metering infrastructure[END_REF] discuss a design for evolution to maintain operation regardless of SoS state and [START_REF] Merabti | Critical infrastructure protection: A 21st century challenge[END_REF] describe the importance of designing solutions that consider security without detailing these solutions.

As no ADL have been developed to model SoS security, we studied existing techniques that address system security.

To determine their usefulness for SoS, we analyzed them regarding the following criteria which seem essential to meet our objectives: model and discover security cascading attacks in the context of the SoS (table I). Indeed, to model security, we prefer to remain general to cover many security concerns (like integrity, confidentiality and access control), so we choose this aspect as a criteria; while we select some additional criteria, like attack, threat, vulnerability and context, specific to the SoS cascading attack security problem that we treat in our work. Another important criteria is the goal concept because it is necessary to model SoS aspects like global goal, individual goals and security goals. Furthermore, since we are following the MDE approach, the modeling language upon which they are based and their ability to support model transformations are important criteria. An extra criteria, which is not in the thick of the current work, is security prediction. This will be useful for future work in order to predict cascading attack paths.

UMLSec is a UML extension proposed by Jurjens [START_REF] Jurjens | UMLsec : extending UML for secure systems development[END_REF] to express security requirements like data secrecy and integrity, information flows restrictions and role based access control.

SecureUML is an approach based on role based access control with additional support for specifying authorization constraints. It was proposed to increase the productivity and quality of secure distributed systems [START_REF] Lodderstedt | SecureUML : A UML-Based Modeling Language for Model-Driven Security[END_REF].

Secure i* is a goal oriented approach used to model and analyze security trade-offs among competing goals of multiple actor systems and quantitatively assess security mechanism's impact on actor's goals and threats [START_REF] Elahi | A goal oriented approach for modeling and analyzing security trade-offs[END_REF].

MoDELO is a MOdel-Driven sEcurity poLicy approach that extends UMLSec with OrBAC elements for early modeling and evaluation of access control requirements [START_REF] Arzapalo | MoDELO: a MOdel-Driven sEcurity poLicy approach based on Orbac," 8ème conférence sur la Sécurité des Architectures Réseaux et des Systèmes d'Information[END_REF].

SysML-Sec [START_REF] Apvrille | Towards the model-driven engineering of secure yet safe embedded systems[END_REF] is a SysML based MDE environment inspired by KAOS. SysML-Sec process includes three stages: system analysis (identification of security requirements and threats by system's partitioning), system design (implementation of software security mechanisms) and system validation (formal verification, simulation and test of the models).

The analysis of the listed approaches is presented in table I. Plus and minus signs means that the evoked criteria are, respectively, taken or not into consideration by the analyzed security modeling languages. This analysis shows that none of the studied ADL satisfy all the investigated criteria. Hence concepts from each approach should be used by any future ADL to be proposed (like the concepts marked in red in table I. In addition, other concepts need to be proposed to represent the cascading attack, and to explicitly model threats and vulnerabilities.

III. PROPOSAL: SOS SECURITY DSML

After identifying the limitations of the existing languages and security extensions in modeling SoS when taking into account their characteristics and security, specially attacks, we now detail the abstract and concrete syntax of our SoSSec language.

As mentioned before, to represent SoS structure and behavior, we extend the SysML MetaModel by modifying the Block Definition Diagram and proposing two new diagrams: security and goal diagrams. For the security diagram, we p artially leverage existing security modeling language semantics such as SysML-Sec, Secure i*, MoDELO and UMLSec by adding new concepts and relations to represent vulnerabilities and cascading attacks. As for the goal diagram, we propose SoS specific concepts, with additional concepts inspired from [START_REF] Guessi | Characterizing architecture description languages for Software-Intensive SoS[END_REF][21] like global goal and individual goal.

Extending SysML and introducing new diagrams means that we have one unifying MetaModel and several views on it (defined as diagrams). Having a unified MetaModel has the advantage of not having to deal with composition of models. If we defined a family of DSMLs, each with their own MetaModel, each corresponding to a view or a purpose, the models created with these DSMLs would need to be composed/combined in order to obtain a complete overview. This would result in important composition challenges [START_REF] Vallecillo | On the Combination of Domain Specific Modeling Languages[END_REF] to address, while from the user/modeler point of view, both approaches result in similar functionalities of several views.

A. SoSSec Abstract and Concrete Syntaxes

SoSSec MetaModel is an extension of SysML MetaModel, indeed, we modified Block definition diagram (Fig. 1) to model SoS, their interfaces and operations on these interfaces. Additionally, we propose two new diagrams: Goal Diagram (Fig. 2) to model SoS global goal and CS's individual goals as well as necessary refinement relationships between these goals; and Security Diagram (Fig. 3) to illustrate the cascading attack security problem.

1) Block Definition Diagram: In SoSSec MetaModel, we use Block to represent SoS structure (Fig. 1), since Block could be used to describe a system or other elements of interest (hardware, software, data, procedure, facility, person). Theoretically, an SoS could be refined into one or many other SoS, e.g. a smart city SoS may encompass a smart grid/building/transportation SoS. The latter idea could be modeled using the composition relationship block. Another aspect that we introduce to SysML MetaModel is GlobalGoal to explicitly represent SoS aim(s). GlobalGoal(s) could be refined_into one or many individual goal achieved by its CSs.

Further, each SoS is composed of many CSs which are usually unstable because of the evolution characteristic. Collaborations between these CS are unknown due to the emergent behavior (e.g. the operations related to the achievement of global goals). During CS's modeling, it is important to well describe the interfaces because CS regular and emergent functionalities are represented at the interfaces, as well as the interactions between CSs and security aspects related to these functionalities and interactions. Mair evoked that "The greatest leverage in system architecture is at the interfaces. The greatest dangers are also at the interfaces. There is nothing else to architect" [START_REF] Maier | Architecting principles for SoS[END_REF].

For these reasons, we model CS as "black-boxes" using InterfaceBlock. These CSs participate in the realization of SoS objective(s) through individual goals and ItemFlow (data, energy, material) exchange. Every CS has interaction points represented by Port which serve to establish connections with other CS to accomplish one or more Operation(s). To better model Operation(s) on interfaces due to their importance in the description of CS functionalities, we modify the latter SysML concept by making it a <graphical node>. As for the SysML Port concept, we adopt it without modifications.

Even if CSs collaborate within the SoS to accomplish its GlobalGoal(s), they remain managerially and operationally independent. To model these aspects, we introduced Organization concept to SysML block diagram. It serves mainly to tie a CS with the organization in which it works. The Organization will be responsible of the functional as well as non functional goals of the CS under its governance, specially security goals. Moreover, Threat concept was also introduced to SysML BlockDefinitionDiagram to make the link between with SecurityDiagram. 2) Goal Diagram: As mentioned earlier, the CSs collaborate in order to accomplish a GlobalGoal assigned to the SoS [START_REF] Maier | Architecting principles for SoS[END_REF]. This GlobalGoal is_refined_into IndividualGoal(s) accomplished by different CS [START_REF] Silva | On the characterization of missions of SoS[END_REF]. The GoalDiagram (Fig. 2) is a new diagram we introduce to model the Goal aspects of SoS. Goal and Block are duplicated in both BlockDefinition and Goal diagrams to make the link between them.

To clearly model SoS non-functional properties, precisely security, we refined Goal into two sub-categories: Functional-Goal and non functional goals precisely SecurityGoal which describe respectively usability SoS and/or CS goals (what a system is supposed to accomplish) and quality goals which influence the operations of the SoS e.g. security (how a system is supposed to be).

Another aspect that seems essential to model the latter quality goals is the concept of Mechanism used to operationalize a Goal. To benefit from this concept, in the context of SoS security architecture modeling, we instantiate it into SecurityMechanism. In order to operationalize (satisfy) security NunFunctionalGoal, most approaches use one or more security mechanisms, e.g. access control and encryption. These SecurityMechanism help to detect, prevent and/or recover from an attack/Threat. The SecurityMechanism and Threat concepts are duplicated in Goal and Security Diagrams to make the link between them.

3) Security Diagram: In our work we choose to describe the cascading attack problem which is a crucial security problem with destructive consequences in the context of SoS as detailed in section I. Indeed, the collaboration between independent CS for the achievement of SoS global goal(s) results in emergent behaviors. In this context, small, known, unresolved and insignificant Vulnerabilities in each CS could be exploited and connected in an unknown way, to form a cascading attack. It is important to mention that in this work we address the unknown known vulnerabilities category. Indeed, Rumsfeld [START_REF] Rumsfeld | Known and Unknown: a memoir[END_REF] classify the knowledge in three cate- gories: known knowns, known unknowns, unknown unknowns. Sawyer [START_REF] Rashid | Discovering unknown known security requirements[END_REF] added a complementary category, on which we will focus: the unknown knowns. He defined it as "knowledge that a person holds, but which they withhold". These categories could be projected onto vulnerability categories. In the context of SoS, each CS may define a list of its own vulnerabilities (known). Since there is no central authority in the SoS, this list of vulnerabilities will remain unknown by other CS, hence the nomination unknown known vulnerabilities.

To be able to model this cascading attack security problem, we propose the SecurityDiagram given in (Fig. 3), to extend SysML with security concepts. These concepts, will serve to discover, analyze and evaluate cascading attacks early at modeling level of the SoS development life cycle.

Each CS may have one or more Threat(s) or malicious goal(s). It represents a possible risk that might be exploited by one or many vulnerabilities to break a SecurityGoal. A security vulnerability is any weakness in or back door to a system [START_REF]Information technology -Security techniques -Information security management systems -Overview and vocabulary[END_REF]. Examples of most common vulnerabilities in many computer systems are "buffer overflow" and "password cracking" [START_REF] Anderson | Security engineering: a guide to building dependable distributed systems[END_REF]. One or several vulnerabilities exploit one or several Threat(s). A Threat is activated by one or many Precondition(s) and activates one or many Postcondition(s) causing damages and loss in an SoS and could lead to an important cascading attack. Precondition(s) [START_REF] Silva | On the characterization of missions of SoS[END_REF] are condition(s) which activates a threat. For example, a pre-condition of the "buffer overflow" vulnerability could be "execution stack by overwriting the stored return address, the stack pointer or the frame pointer". Whereas, Postcondition(s) [START_REF] Gallon | Cvss attack graphs[END_REF] represent the results of an activated threat. For example, the results of a "buffer overflow: could be an "unauthorized access to system". The effect could directly affect the concerned CS or could lead to a cascading attack that influence the whole SoS.

After defining SoSSec's abstract syntax, we adopt existing visual notations to represent it. Indeed, defining a DSML undertakes corresponding one or many concrete syntax(es) to its abstract syntax. The concrete syntax is a set of textual or visual notations that facilitates the language presentation and construction. As SoSSec MetaModel is a SysML extension, we adopt existing related visual notations (e.g. nodes and edges) to represent model elements.

B. SoSSec Graphical Editor Development

SoSSec abstract syntax (MetaModel) is specified using the Eclipse Modeling Framework (EMF) and its concrete syntax (graphical editor) is (semi)automatically generated using model transformations through the Graphical Modeling Framework (GMF). We choose EMF/GMF tooling because they are open source, recently used by the community, well documented relatively easy to use and support MDE. First, we specified our abstract syntax using Ecore, which is the MetaModel of the EMF 5 . Then, the Ecore model was used within the GMF to generate (parts of) the graphical editor. In fact, GMF provides the fundamental infrastructure and components for developing visual models and modeling surfaces in Eclipse. Having SoSSec MetaModel (Ecore model), GMF allows the definition of diagrams based on a mapping between the abstract and the concrete syntaxes and the (semi)automatic generation of the corresponding graphical editor (visual tool). This graphical editor corresponding to our SoSSec DSML (Fig. 6) could now be used by SoS security architects to model their SoS taking into account its specific characteristics and security aspect related to the cascading attack security problem.

C. Discussion

Having SoSSec DSML will allow to an SoS (security) architect to discover unknown known sequence of CS's vulnerabilities that could be triggered resulting in destructive cascading attacks. An architect will be able to model, using SoSSec graphical editor, the structure of an SoS taking into account its specific characteristics (like CSs, Interfaces, global and individual goals) as well as SoS behavioral aspects (like interactions, operations and exchange of data.). In addition, an architect will be able to describe a list of vulnerabilities for each CS, including the pre-condition(s) that trigger each vulnerability and the resulting damages (post-condition(s)). Once the SoS Security model is designed, the architect could simulate it through a simulation approach like Multi-Agent Systems (MAS) (we are currently working on this semantic part of SoSSec DSML). The simulation will allow the discovery, at the architecture level of the SoS development life cycle, of possible unknown sequences of known vulnerabilities. Thus, cascading attacks could be discovered and analyzed at an early stage and corrective actions could be applied to prevent the cost, development time and effect of later changes.

IV. SMART CAMPUS CASE STUDY

SoS have many application domains, such as defense, cyberspace, health-care and electrical power grids. A more recent SoS domain with growing popularity is Smart Cities. According to [START_REF] Babar | Smart cities: Socio-technical innovation for empowering citizens[END_REF], 80% of the world's population will be living in cities by 2020. There are estimates that smart cities market will attain 14 Bn EUR addressable revenue by 2020 and 400 Bn Dollars per year will be dedicated for smart urban systems [START_REF] Association | Smart cities, developing collaborative mobilebased city solutions for smart cities[END_REF].

Design and implementation of smart cities initiatives are complex and challenging tasks. Thus, it is more reasonable to design and implement solutions on a smaller but realistic scale [START_REF] Babar | Smart cities: Socio-technical innovation for empowering citizens[END_REF]. Hence, to demonstrate our proposition, we chose to model a small-scale view of a smart city SoS: the smart campus. Indeed, smart campus have similar operationnaly and managerially independent CS such as smart lighting system and similar global goals that implies the intervention of many CSs to be achieved such as an efficient energy management and security.

Therefore, a smart campus could be analyzed as an SoS with the following CSs: smart lighting system; air-conditioner and heaters; temperature and humidity sensors and control systems; smart energy system; spatial awareness sensors and data analysis system; monitoring cameras, alarm, video surveillance and security control; internet network; smart vehicles, bicycles, parking These CS need to collaborate in order to achieve some global goals, such as: monitor the building use (energy The modeling of the latter global goal are presented in Fig. 5: Smart Campus global goal is refined into individual goals to be realized by CS: HVAC CS individual goal is to regulate the temperature in rooms, Weather Station CS has the individual goal is to capture weather information and the individual goal of Smart Access Control CS is to regulate the access to the room. An operation could be menaced by a threat and an individual goal could be refined into a security goal to make the link with the security diagram (Fig. 6).

In order to give a small example of a cascading attack problem within the described smart campus, we associate two threats: "exceed high temperature limit" and "data modifi-cation" respectively to the HVAC CS and Weather Station CS. Each threat is described with a security diagram (Fig. 5) showing:

1) The corresponding vulnerability: "data modification" threat could be exploited by "SQL injection" or "weak authentication" vulnerability" and "exceed high temperature threat" could be exploited by HVAC CS "production default" vulnerability (Fig. 6); 2) Security goal(s) broken by the threat are also represented in the security diagram: "data modification threat" break "Prevent Information modification by unauthorized person" individual goal and "exceed high temperature limit" threat break "prevent dysfunction of the heater" individual goal (Fig. 6); 3) The pre-condition which activates the threat and the postcondition which results from the activated threat: "data modification" threat is activated by the pre-condition "possibility of sending unauthorized database query" and results-in "abnormal temperature information" postcondition (Fig. 6) and "exceed high temperature limit" threat is activated by the pre-condition "abnormal high temperature information" and results-in "heater explosion" post-condition causing fire in the HVAC CS. Having these models, we can imagine the following emerging cascading security problem resulting from the collaboration between CS to achieve the smart campus global goal. Normal Scenario:

1) Weather station CS send ambient temperature information to HVAC CS 2) According to the received information, HVAC CS adjusts its heater, air-conditioner temperatures 3) HVAC CS measure inside temperature room and send it to the Smart Access Control CS 4) The latter analyze the information in order to allow/prevent access to the room Cascading attack scenario: 1) Ambient temperature information is decreased by an attacker taking advantage of the temperature monitoring CS's vulnerability: SQL injection or weak authentication 2) HVAC CS acts upon the received erroneous information by increasing heater's temperature. This action exploits another small vulnerability related to HVAC CS which is "exceed high temperature limit" 3) The latter vulnerability lead to heater explosion causing a fire in the room 4) Thus the Smart Access Control System will permit doors opening so staff could leave the room (and maybe any non-allowed person will enter the room at this moment.) We illustrated a small example of a cascading attack security problem in smart campus case study. In the same way, more complex scenarios could be discovered having the security models of our SoS.

V. CONCLUSION System of Systems (SoS) architecture is a promising research field gaining increasing importance. SoS are comprised of complex distributed constituent systems (CS) which need to collaborate to achieve their own local goals as well as global SoS goal(s). These interactions may cumulate or trigger a sequence of small security vulnerabilities coming from different CS. These cascading vulnerabilities may serve, intentionally or unintentionally, to compose a cascading attack that affects the whole SoS and causes huge important damages.

In this work, we focused on this security problem. We introduced a DSML, a SysML extension, to model SoS security early at the architecture level of the development life cycle to reduce the cost, time and effect of later modifications. We followed a Model Driven Engineering approach to define the SoSSec parts (concrete syntax, abstract syntax). This paper describes the details of the abstract syntax of our languagethe MetaModel, and its concrete syntax with the corresponding graphical editor. Our SoSSec DSML has been used to model a motivating smart campus case study and has illustrated a possible cascading attack scenario. In the future, we plan to develop the semantics of our language in order to simulate, analyze and quantitatively predict security of an SoS architecture. We also aim to extend a well known graphical editor in the enterprise and research communities such as Papyrus to have a complete and easy extensible tool compatible with existing SysML models.

Fig. 1 .

 1 Fig. 1. SoSSec MetaModel Block Diagram.

Fig. 2 .

 2 Fig. 2. SoSSec MetaModel Goal Diagram.

Fig. 3 .

 3 Fig. 3. SoSSec MetaModel Security Diagram.

Fig. 4 .

 4 Fig. 4. Smart Campus Model -Block Diagram

Fig. 5 .

 5 Fig. 5. Smart Campus Model -Goal Diagram

Fig. 6 .

 6 Fig. 6. Smart Campus Model -Weather Station and HVAC CSs Security Diagrams

TABLE I ADL

 I COMPARISON FOR SYSTEMS SECURITY MODELING

		UMLSec	Secure UML	Secure i*	MODELO	SysML -Sec
		Integrity
		Authenticity				Authenticity
	Security concerns	Access-Control Confidentiality	Access Control	Access Control	Access Control	Confidentiality Integrity
		Non-Repudiation				Autonomy
		Non-Interference
	Modeling Language	UML	UML	UML	UML	SysML
	Model Transformations	Model to Text	Model to Text	?	Model to Model	Model to Text
	Threat-Vulnerability concepts	-	-	+	-	-

http://www.silicon.fr/irongate-un-malware-aux-airs-de-stuxnet-cible-lesscada-149299.html; accessed

on 21st June 2016

http://www.compass-research.eu/; accessed on 21st June 2016

http://danse-ip.eu/home/; accessed on 21st June 2016

http://road2sos-project.eu/; accessed on 21st June 2016

http://www.eclipse.org/modeling/emf/


Aymen Belghith

Loutfi Nuaymi

Patrick Maillé

Pricing of differentiated-QoS services WiMAX networks

WiMAX/IEEE 802.16 system is a very open Broadband Wireless Access (BWA) technology with different possible services. Pricing of WiMAX is an important topic with different optimization possibilities. In a previous paper, we investigated WiMAX pricing for real-time applications (Unsolicited Grant Service (UGS) and real-time Polling Service (rtPS) QoS classes of WiMAX) [7]. We add the Best Effort (BE) QOS class in this paper in order to have a rather complete WiMAX environment. The system model is described. Then we consider two different BE pricing mechanisms: fixed price and auction-based variable price. The proposed methods are evaluated through simulations in order to have some interesting comments and highlights for WiMAX pricing.

I. INTRODUCTION

WiMAX is a powerful Broadband Wireless Access (BWA) technology. It is based on the IEEE 802.16 standard [1] and its amendment [START_REF]IEEE Standard for local and metropolitan area networks, Air Interface for Fixed Broadband Wireless Access Systems, Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands and Corrigendum 1[END_REF]. WiMAX has a very rich set of features in order to have a highly-efficient use of the radio resource while transmitting different service types which allows different constraints.

The IEEE 802.16 BWA system has three possible physical (PHY) layers: Single Carrier (SC), Orthogonal Frequency Division Multiplexing (OFDM), and Orthogonal Frequency Division Multiple Access (OFDMA). WiMAX retains only OFDM and OFDMA. Both Duplexing modes are possible: Time Division Duplexing (TDD) and Frequency Division Duplexing (FDD). For topologies, Point-to-MultiPoint (PMP) and Mesh modes can be used. We consider the PMP transmission mode and the FDD duplex mode. Our study could be extended to the TDD mode, with additional latitude.

The IEEE 802.16 standard Medium Access Control (MAC) layer provides QoS differentiation for the different types of applications that might operate over 802.16 networks, through the defined Scheduling Service Types also called QoS Classes. There are five QoS classes in IEEE 802.16. Four classes of QoS were defined in 802.16-2004 standard : Unsolicited Grant Service (UGS), real-time Polling Service (rtPS), nonreal-time Polling Service (nrtPS), and Best Effort (BE). A fifth one has been added with 802.16e amendment: extended real-time Polling Service (ertPS) class. The MAC Convergence Sublayer (CS) operates the classification of the different users applications in those five classes.

For these different services transmitted in a quickly varying wireless environment, the pricing strategy is an open problem, actually an important and challenging one. Pricing models are defined for the integration of WiMAX and Wireless Fidelity (WiFi). A strategy game used in economics, called Stackelberg leadership model, is used in [START_REF] Niyato | Integration of WiMAX and WiFi: Optimal Pricing for Bandwidth Sharing[END_REF], in order to propose a pricing model for sharing bandwidth between WiMAX and WiFi users. Other pricing models are defined only for WiMAX context. Two market models are defined in [START_REF]Business Case Models for Fixed Broadband Wireless Access based on WiMAX Technology and the 802.16 Standard[END_REF]. The Base Station (BS) allocates resources only for the residential users in the first market model. In the second model, the BS also provides services to the Small and Medium Enterprises (SME) customers. In [START_REF] Lee | Price-based distributed algorithms for rate-reliability tradeoff in network utility maximization[END_REF], a pricing model for wireless networks users is proposed. The utility function of the proposed pricing model depends on the transmission rate and the quality of the channel. In [START_REF] Chang | Adaptive Hierarchical Polling and Cost-based Call Admission Control in[END_REF], a cost-based Call Admission Control (CAC) is proposed for IEEE 802.16 WiMAX. It is based on the required bandwidth and the residual bandwidth. The competitive On-Line (COL) is used in order to have an exponential cost function of the residential bandwidth. Since WiMAX operators can use different pricing strategies for the QoS classes, we propose pricing schemes for two WiMAX QoS classes in [START_REF] Belghith | Pricing of Real-Time Applications in WiMAX Systems[END_REF]. Our pricing model is designed for real-time applications.

In this paper, we propose two different pricing schemes for the BE QoS class in an environment where the UGS and rtPS QoS classes are also considered.

This paper is organized as follows. In Section II, we present the system model. Then, we describe our pricing proposals for UGS, rtPS, and BE QoS classes. In Section III, we present some simulation results for our two proposed BE pricing mechanisms. Conclusions and directions for future work are provided in Section IV.

II. SYSTEM MODEL

A. WiMAX model

We consider a simplified environment with only three QoS classes of WiMAX services (out of the five standard-defined classes):

• UGS: supports real-time service flows that have fixed-size data packets on a periodic basis designed for circuit-type voice services, for instance. • BE: designed for non-real-time applications where no guarantee is provided. This class should evidently be the cheapest one. An objective of a pricing scheme could be to maximize the network revenue, while still satisfying some fairness constraints. Pricing schemes objectives and equity constraints are studied in this paper. We are moreover looking for a scheme that remains simple to implement and to understand for users.

Different frame duration and bandwidth values can be used in IEEE 802.16. For a given system, the frame has a fixed number of OFDM symbols (N OF DM ) when the OFDM PHY layer is considered. The number of symbols depends on some parameters such as the frequency bandwidth and the Cyclic Prefix (CP). An appropriately-designed pricing mechanism should then properly allocate those symbols among users, so as to satisfy some QoS agreements, or maximize user satisfaction or provider revenue. The number of useful data bits is indeed variable and depends on the Modulation and Coding Scheme (MCS) used by the considered user. The MCS to be used is defined by the link adaptation procedure. The choice of the appropriate MCS depends on the value of receiver Signalto-Noise Ratio (SNR). The transmitting station (BS or SS) switches to a more energy-efficient MCS if the SNR is good. It switches to a more robust MCS if the SNR is poor. Once the MCS is defined, the number of bits per OFDM symbol, and then the useful number of bits per frame, is known as shown in Table I. The BPSK modulation is mainly used for management purposes and will not be considered in this work. Therefore, the BS must take into account link adaptation in its scheduling considerations. The link adaptation process must also be taken into account in the pricing scheme.

B. Pricing Model

We propose a utility function for each type of service. The utility is the difference between the price that the user is willing to pay for the service (that we call valuation or willingness to pay) and the price actually paid. The utility, valuation, and price actually paid are per unit of time.

U (r) = V (r) -P (r) (1)
where:

• U: represents the utility function.

• V: represents the valuation function.

• P: represents the price actually paid function.

• r: represents the throughput of the connection (expressed in kbit/s).

1) UGS users:

The transmission rate of the UGS connections is fixed at the beginning of the session. We consider that each UGS user i is willing to pay a given price v i per transmitted kbit per second.

V U GS (r) = v i • r (2)
We suggest to use a pricing scheme based on two prices.

P U GS (r) = P U GS Low • r, if nbres nb tot ≤ th U GS P U GS High • r, otherwise (3)
where:

• P U GS Low : represents the price charged when the network is not congested. • P U GS High : represents the price charged during the congestion periods. We consider that P U GS High = α U GS • P U GS Low . • nb res : represents the number symbols already reserved for the UGS connections. • nb tot : represents the total number of symbols per frame.

• th U GS : represents a threshold that determines when the network is congested. 2) rtPS users: rtPS services offer a flexibility in the transmission rate. We therefore consider that users have elastic demand, i.e. their valuation function is increasing and concave in the transmission rate r.

V rtP S (r) = v i • ( -r 2 R i max + 2r), if r ≤ R i max v i • R i max , otherwise (4)
where:

• r: represents the reserved rate.

• v i : represents a constant coefficient (in monetary unit (MU) by kbit/s transmitted). • R i max : represents the maximum transmission rate of the connection i. An rtPS user i with transmission rate r that belongs to [R min , R max ] is charged a price:

P rtP S (r) = P rtP S min • R min + P rtP S add • (r -R min ) (5)
where:

• P rtP S min : represents a fixed unit price for R min . It is independent of the congestion. • P rtP S add : represents a variable unit price for the additional transmission rate. It increases with congestion. The price for extra rate is chosen as:

P rtP S add =
C rtP S nb rem min [START_REF] Chang | Adaptive Hierarchical Polling and Cost-based Call Admission Control in[END_REF] where:

• C rtP S : represents a pricing constant fixed by the operator.

• nb rem min : represents the number of OFDM symbols remaining after all the UGS users are served and the rtPS users get their minimum transmission rate.

3) BE users: The BE connections have no QoS guarantees. Therefore, the BE users have flexibility in their transmission rate. We consider that their valuation function is increasing and concave in the number of reserved symbols s. We propose:

V BE (s) = γ i • ( -s 2 Smax + 2s), if s ≤ S max γ i • S max , otherwise (7)
where:

• s: represents the number of reserved symbols.

• γ i : represents a constant coefficient (in MU by reserved symbol). • S max : represents the number of reserved symbols above which the valuation of BE users remains constant.

We also introduce heterogeneity among the BE users by assuming that γ i is randomly chosen for each user, according to continuous uniform distribution on the interval [Γ1 BE , Γ2 BE ] (in MU by reserved symbol).

The BE calls are charged a price SymbolP rice BE per reserved symbol.

P BE (s) = Symbol P rice BE • s (8)
We then suggest to use two pricing schemes. In the first pricing model, called Fixed Symbol Price Model (FSPM), the operator charges a fixed price SymbolP rice BE per reserved symbol. After serving the UGS and rtPS users, the remaining symbols are equitably distributed between all the BE users, using the Round Robin (RR) scheduler. The number of reserved symbols to each connection also depends on the utility function and the the remaining size of the file to be transmitted.

In the second pricing model, called Variable Symbol Price Model (VSPM), the operator charges, using also [START_REF] Besanko | Microeconomics[END_REF], a variable price Symbol P rice BE per reserved symbol.

As a specific variable prices, we suggest to allocate the OFDM symbols that are not used by UGS rtPS calls using price auctions, i.e. with a pricing scheme that gives symbols to users who value them most. A simple way to obtain such an allocation is to determine the market clearing price [START_REF] Besanko | Microeconomics[END_REF], that is the unit selling price for which the demand of all BE users equals the number of available OFDM symbols. We assume that such an ideal scheme is used. We can imagine auction or tâtonnement methods to converge to this price [START_REF] Wang | Auction or tâtonnement -finding congestion prices for adaptive applications[END_REF]. The definition of the practical details of the auction mechanism in WiMAX system can be an interesting future topic of research.

The main objective of VSPM is to find the maximum reserved symbol price while reserving all the remaining symbols. From [START_REF] Belghith | Pricing of Real-Time Applications in WiMAX Systems[END_REF], the number of symbols to reserve for each connection i, noted d i (p), is expressed as follows.

d i (p) = (V i ) -1 (p) = S max • 1 - p 2γ i + (9)
Therefore, the value of Symbol P rice BE is determined as the solution p of the equation:. [START_REF] Nuaymi | WiMAX: Technology for Broadband Wireless Access[END_REF] where:

N user BE i=1 S max • 1 - p 2γ i + = nb BE
• N user BE : represents the number of the BE users.

• p: represents the price of a reserved OFDM symbol.

• nb BE represents the number of remaining symbols to allocate to the BE users. If N user BE ≤ nb BE S max , the solution of ( 10) is negative. In this case, there is no congestion and then we can offer a free access to the network (p = 0).

III. SIMULATION RESULTS

A. Simulation model

This section describes the situation we have considered to simulate the behavior of a WiMAX system under the pricing schemes described in the previous section. In this work, we consider the OFDM PHY layer used in the PMP topology and FDD mode. The number of OFDM symbols per frame (N OF DM ) is constant and depends on the frame duration and the OFDM symbol duration. According to [START_REF] Nuaymi | WiMAX: Technology for Broadband Wireless Access[END_REF], the OFDM symbol duration is computed as follows:

OFDM symbol Duration = 1+G n• BW N F T T
where:

• G: represents the ratio of the guard time to the useful symbol time.

• n: represents the the sampling factor.

• BW: represents the channel bandwidth.

• N F T T : represents the total number of subcarriers. For the OFDM PHY, the total number of subcarriers is equal to 256 (N F T T = 256). For the following parameter values: BW = 7 MHz, n = 8/7, G = 1/8, and frame duration = 10 ms obtain an OFDM symbol duration equal to 35.86 µs and N OF DM equal to 278 symbols. The simulation duration is equal to 300 s.

In our simulation framework, we consider Poisson arrivals of each class of customer UGS and rtPS, with respective arrival rate λ U GS = λ rtP S = λ BE = 1/30s -1 . We assume that the durations of the UGS and rtPS sessions follow exponential distributions with respective mean µ U GS = µ rtP S = 5 minutes. BE sessions correspond to file transfers and their duration therefore depends on the transmission rate experienced. We assume that the size of files to be transmitted by BE sessions follows a Normal law with mean 300 kbit and standard deviation 150 kbit (eventually removing negative values).

We consider three types of UGS users: 10 kbit/s, 50 kbit/s, and 200 kbit/s, that represent 25%, 25%, and 50% of the UGS users, respectively. We also consider four types of rtPS users, with respective R min = 30, 50, 100, 200 (in kbit/s) and R max = 100, 300, 500, 800 (in kbit/s). We assume that each of these [R min , R max ] couples is chosen by 25% of the rtPS users.

The user SNR values are randomly chosen at the beginning of the session, considering a simple cellular model with three cells per cluster: the SNR distribution can then be obtained using classical results of the SNR repartition in cellular networks [START_REF] Lagrange | CIR cumulative distribution in a regular cellular network[END_REF]. Having the SNR values, the MCS used is directly deduced from Table I. The distribution of SNRs (and then MCSs) is given in Table II.

The valuation parameter γ i (in MU by symbol reserved) of the BE users uniformly distributed on the interval [Γ1 BE , Γ2 BE ]. We assume that Γ1 BE = 0.05 Γ2 BE = 0.5.

Since the UGS and rtPS QoS classes are designed for realtime applications, an admission control mechanism is required. An UGS (resp. rtPS) customer is admitted only if there are enough OFDM symbols, taking into account its MCS used, for its data rate (resp. for its minimum data rate R min ).

In this paper, we assume that P U GS Low = P rtP S min = P ref = 0.25. For the UGS pricing model, we adopt α U GS = 2 (P U GS High = 2 * P ref ), th U GS = 0.5. For the rtPS pricing model, we adopt C rtP S = 10. The model details of the UGS and rtPS connections are studied in [START_REF] Belghith | Pricing of Real-Time Applications in WiMAX Systems[END_REF]. In this Section, we only focus on our two pricing models for the BE users.

B. Investigation of S max

Recall that S max represents the number of reserved symbols above which the valuation remains constant (see [START_REF] Belghith | Pricing of Real-Time Applications in WiMAX Systems[END_REF]). Symbol P rice BE is always constant when we use FSPM. However, according to [START_REF] Nuaymi | WiMAX: Technology for Broadband Wireless Access[END_REF], the choice of Symbol P rice BE , using VSPM, depends on S max .

Fig. 1 shows the price of a reserved symbol using VSPM as a function of S max . We note that Symbol P rice BE increases when S max increases. According to [START_REF] Nuaymi | WiMAX: Technology for Broadband Wireless Access[END_REF], the price of a reserved symbol is expressed as follows.

p = N user BE -nb BE Smax N user BE i=1 1 2γi (11)
Hence, the price of a reserved symbol increases when S max increases and converges to N user BE / N user BE i=1 1 2γ i . Fig. 2 shows the mean revenue from the BE connections using VSPM as a function of S max . The mean revenue increases when S max increases and converges to a constant value. This is because the price actually paid depends on Symbol P rice BE (see ( 8)).

Fig. 3 shows the mean throughput of the BE connections using VSPM, the rtPS and UGS connections as a function of S max . We notice that the throughput is independent of S max . Indeed, the UGS and rtPS flows being priority over the BE flows, their throughput is not affected by S max . Moreover, for values of S max above N OF DM , (10) always has a positive

C. Investigation of Symbol P rice BE

In this section, we investigate Symbol P rice BE when we use FSPM because this parameter is determined using auction in VSPM.

Fig. 4 shows the satisfaction percentage of the BE connections using FSPM as a function of Symbol P rice BE . The satisfaction percentage represents the size of all the Mean throughput of BE connections using FSPM versus Symbol P rice BE files already transmitted divided by the total size to transmit. The unsatisfied transfers are due to user refusing the imposed price. We observe that the satisfaction percentage decreases when Symbol P rice BE increases. This is because when the price actually paid increases, it can exceed the valuation function of some BE users until blocking all the users (Symbol P rice BE > 5M U/symbol).

Fig. 5 shows the mean throughput of the BE connections using FSPM as a function of Symbol P rice BE . The mean throughput decreases when Symbol P rice BE increases. This is due to the decrease of the satisfaction percentage.

Fig. 6 shows the mean revenue from the BE connections using FSPM as a function of Symbol P rice BE . The revenue from the BE connections increases when Symbol P rice BE increases without exceeding 0.9 MU/symbol. Indeed, despite the decrease of the satisfaction percentage, the price actually paid increases and most of the BE users still afford buying symbols.

When Symbol P rice BE > 0.9M U/symbol, the revenue from the BE connections decreases when Symbol P rice BE increases. This is because the price actually paid is so high that the majority of the BE users refuse to reserve symbols. We note that there is no revenue from the BE connections Fig. 6.

Mean revenue from BE connections using FSPM versus Symbol P rice BE when Symbol P rice BE exceeds 5 MU/symbol. This is due to the fact that no BE user pay the actual price (see Fig. 4).

We note that FSPM can provide more revenue than VPSM (215 MU when Symbol P rice BE = 0.9M U/symbol). However, to attain this revenue, the satisfaction percentage decreases from 65 % to 35 % and the mean throughput decreases from 170 kbit/s to 100 kbit/s. In practice, even if the operator tries to maximize its revenue without taking into account the satisfaction percentage of the BE users, the optimal value of Symbol P rice BE depends on the valuation functions of the BE users. So, the operator has to estimate with accuracy the behavior of the customers because the revenue (and the throughput) can considerably decrease in function of Symbol P rice BE .

On the other hand, using VPSM, the operator does not need to determine the symbol price. This pricing model provides a mean revenue larger than 178 MU and a mean throughput equal to 110 kbit/s. In practice, the objective is to maximize the revenue, satisfy the customers and take into account their power of purchase. The best way is to have an auction-based variable price. In our case, the symbol price is between 0.42 MU/symbol and 0.58 MU/symbol.

D. Investigation of γ i

In this section, we study the behavior of our pricing models against the valuation parameter γ i (in MU by symbol reserved) of the BE users. We consider four continuous uniform distributions on [Γ1 BE , Γ2 BE ]: [0.01, 0.05], [0.05, 0.5], [0.5, 0.75], and [0.75, 1]. Fig. 7 shows the price of a reserved symbol using VSPM as a function of S max . We observe that the mean symbol price increases when γ i increases. This is due to the increase of the willingness-to-pay of users (see [START_REF] Belghith | Pricing of Real-Time Applications in WiMAX Systems[END_REF]).

Fig. 8 shows the mean revenue from the BE connections using VSPM as a function of S max . The revenue from the BE connections increases when γ i increases. This is due to the increase of the symbol price. Indeed, the operator must profit from the increase of the valuation functions of the customers. Fig. 9 shows the mean revenue from the BE connections using FSPM as a function of Symbol P rice BE . We note that Mean revenue from BE connections using FSPM versus Symbol P rice BE the symbol price that maximizes the mean revenue increases when γ i increases. Symbol P rice BE must be changed from 3 MU/symbol to 4.5 MU/symbol when BE customers use [0.5, 0.75] instead of [0.75, 1]. Then, it is recommended to take into account the users behavior dynamically in order to determine the value of symbol Symbol P rice BE maximizing the operator revenue.

IV. CONCLUSION In this paper, we investigated some pricing schemes for a WiMAX system with different classes of QoS. We focus on BE class pricing. We propose two pricing schemes for BE: fixed and variable symbol price (FSPM and VSPM, respectively). The latter is based on auctions. Extensive simulations are conducted to study the behavior of FSPM and VSPM against the different parameters of the pricing models. We showed that FSPM can provide a higher revenue than VSPM. However, FSPM does not take into account the satisfaction of the BE users and the operator have to change the symbol price at each network change. We also investigated the propriety that made VSPM efficient by determining the suitable value of the price symbol that maximize the revenue while distributing all the remaining symbols after serving all the UGS and rtPS customers.

As directions for future work, we can mention the observation of other QoS indicators such as the delay (average or maximum). New pricing optimization considerations should be addressed. The adaptation and application of the proposed schemes to the (Mobile WiMAX) OFDMA Layer is another interesting topic of research as an OFDMA subchannel is a less rigid unit than an OFDM Symbol, especially if we take into account the different types of subchannels defined in IEEE 802.16: full usage of subchannels (FUSC), partial usage of subchannels (PUSC) and Band Adaptive Modulation and Coding (AMC).

Fig. 1 .Fig. 2 .

 12 Fig. 1. Symbol P rice BE versus S max

Fig. 3 .

 3 Fig. 3. Mean throughput of BE connections using VSPM versus S max

Fig. 4 .

 4 Fig. 4. Satisfaction percentage of BE connections using FSPM versus Symbol P rice BE

Fig. 7 .Fig. 8 .

 78 Fig. 7. Symbol P rice BE versus S max

TABLE II DISTRIBUTION

 II OF THE MCSS FOR ARRIVING USERS

	SNR range (dB) Proportion of users
	[6, 8.5)	30 %
	[8.5, 11.5)	10 %
	[11.5, 15)	20 %
	[15, 19)	15 %
	[19, 21)	5 %
	[21,+∞)	20 %