D4.1: Layer 2 & 3 Simulation Platform Description

Transcription

1 IST MATRICE D4.1: Layer 2 & 3 Simulation Platform Description Contractual Date of Delivery to the CEC: End December 2002 Actual Date of Delivery to the CEC: 6 January 2003 Author(s): J.Rodriguez (UniS), D.T.Phan Huy (FTR&D), R.Aguiar (IT), F.Berens (ST) Participant(s): UniS, FT R&D, IT, and ST Workpackage: WP4 Est. person months: 5 Security: Pub Nature: R Version: 1.0 Total number of pages: 68 Abstract: This deliverable aims to satisfy the requirements of activity A4.1 stated in the technical annex, and to achieve milestone M4.1.: Layer 2&3 simulation platform specification. D4.1 is a specification document of the dynamic system level simulator V.0., based on constraints from WP1, and WP2. The key building blocks of the simulator architecture are defined and specified. Keyword list: Dynamic System Level Simulator V.0, Radio Resource Management, Multiple Access Control, IP Interface, Link Level Interface, MC-CDMA, Dynamic Channel Allocation, DiffServ, Scheduling.

2 Abbreviations MC-CDMA CDMA DCA RRM IP QoS RAN DiffServ IETF RSVP IntServ CIP MIP TCP 3GPP RLC MAC PER HO CAC PC PDU SDU ARQ FCA FPC SIR RNC PLMN SGSN GGSN RNC MSC GMSC Multi-Carrier CDMA Code Division Multiple Access Dynamic Channel Allocation Radio Resource Management Internet Protocol Quality of Service Radio Access Network Differentiated Services Internet Engineering Task Force Resource Reservation Protocol Integrated Services Cellular IP Mobile IP Transmission Control Protocol 3 rd Generation Project Partnership Radio Link Control Multiple Access Control Packet Error Rate Handover Call Admission Control Power Control Protocol Data Unit Service Data Unit Automatic Repeat Request Fixed Channel allocation Fast Power Control Signal to Interference Ratio Radio Network Controller Public Land Mobile Network Serving GPRS Support Gateway Gateway GPRS support node Radio Network Controller Mobile Switching Centre Gateway MSC

3 VLR HLR GSM PU VoIP Visitors Location Register Home Location Register Global System for Mobile Communication Protocol Unit Voice over IP

4 Table of contents ABSTRACT INTRODUCTION MATRICE SYSTEM LEVEL VISION SYSTEM LEVEL DESIGN METHODOLOGY IP DESIGN APPROACH OVERVIEW OF D SYSTEM LEVEL OBJECTIVES SYSTEM LEVEL SCENARIO System Level requirements from Layer CONCLUSION SYSTEM LEVEL EVALUATION TOOL DEFINITION INTRODUCTION LAYERED STRUCTURE DEFINITION LINK LAYER TECHNOLOGY SIMULATOR SPECIFICATIONS Task Management Domain Human Interaction Domain Problem Domain RADIO RESOURCE MANAGEMENT PROTOCOL RRC Architecture RRC Service States RRC Functions OOA SIMULATOR SPECIFICATION OO Simulator Structure Object Interface Definition Results Domain Problem Domain Simulator Flow Chart CONCLUSION DESIGN METHODOLOGY APPROACH FOR IP CONVERGENCE LAYER IP INTERFACE METHODOLOGY IP INTERFACE DEFINITION Downlink Implementation Uplink Implementation INTERFACE DEVELOPMENT Interface Integration LINK LEVEL INTERFACE SPECIFICATION INTRODUCTION PHYSICAL LAYER INTERFACES TO HIGHER LAYERS TRAFFIC CLASSES INTERFACE MODELS TO THE LINK LEVEL SIMULATOR CONCLUSION...65 REFERENCES...68

5 List of figures Figure 1: Conceptual MATRICE RAN architecture Figure 2: UMTS architecture Figure 3: Layered structure model Figure 4: Link layer technology Figure 5: Simulator structure Figure 6: RRC layer architecture Figure 7: RRC service states Figure 8: Service modes for Beyond 3G systems Figure 9: OO simulator structure Figure 10: Task Manager object Figure 11: Task Manager flow sequence Figure 12: Event Scheduler object Figure 13: Event class Figure 14: Service start event object Figure 15: Results Database object Figure 16: Service class Figure 17: Speech Service object Figure 18: Mobile Manager object Figure 19: Mobile object Figure 20: Mobility Data object Figure 21: HandOver Table object Figure 22: Random Generator object Figure 23: Cell Manager object Figure 24: Radio Resource Management object Figure 25: Service Queue object Figure 26: Mobility Model object Figure 27: Base Station Manager object Figure 28: Base Station Resource allocation Figure 29: Base Station object Figure 30: Channel Model object Figure 31: Link Level Interface object Figure 32: Flow chart of simulator structure Figure 33: Proposed IP interface structure Figure 34: Downlink IP layer structure Figure 35: Downlink radio layer Figure 36: Uplink IP layer structure... 58

6 Figure 37: Uplink radio layer Figure 38: Simplified radio interface protocol architecture with interfaces to the physical layer Figure 39: Link level simulation set-up with system level interface... 64

7 List of tables Table 1: MATRICE QoS classes Table 2: Reference simulator specification Table 3: Possible data traffic with QoS criterions for the physical layer packet sources Table 4: WP4 Specification table... 66

8 Abstract This deliverable aims to satisfy the requirements of activity A4.1 provided in the MATRICE technical annex, and to reach milestone M4.1.: Layer 2&3 simulation platform specification. D4.1 is a specification document of the reference dynamic system level simulator V.0., based on constraints from WP1, and WP2. The key building blocks of the simulator architecture are defined and specified. In particular, the Radio Resource Management functions and Dynamic Channel Allocation are investigated. These are developed further to provide a clear software classification using an Object Oriented Analysis approach. Attention is also given to the design of the IP interface, to provide seamless connectivity to the IP core network envisaged by MATRICE. The interface architecture, and functionality for both uplink and downlink flows are examined. Moreover, a discussion of the Link Level interface reveals a description of the physical layer interfaces, and a definition is provided on the interactions between physical layer and link level simulators. The sequel will provide a description of the Link Layer algorithms, where the analysis will reveal the algorithmic assumptions and modelling of the Radio Resource Management and MAC layer entities, and their interactions with the simulator V.0. D1.1 provides a description of the simulator scenarios, whilst D1.3 describes the evaluation methodology and criteria, the default test environments and the default test services. This document has been compiled in close collaboration with FT R&D, IT, and ST, which have been the main contributors to this deliverable.

9 1 Introduction 1.1 MATRICE System Level Vision MATRICE is a project that attempts to provide a definition to the fourth generation of wireless systems, however the scope of a 4G system encompasses the integration of broadband networks with a common network layer; an all IP network. MATRICE is focused on a specific entity within a 4G system. The intention is to generate the framework for the specification of a beyond 3G wireless system, with the objective to provide high capacity capability to support future emerging services. Moreover, the design of such a system will have an impact on future markets, manufacturers, regulatory bodies and the operators. These mould the requirements and scenarios of future systems, it is a requirement for wireless systems to provide greater efficiency to meet future traffic requirements, and to be more cost effective in the presence of scarce radio resources. In addition, future networks will evolve to provide preferential treatment to QoS traffic, MATRICE will need to accommodate such mechanisms, and to support true intersystem roaming between IP network. These network related design issues will be addressed by an IP convergence layer. In MATRICE WP4, the impact of these design objectives on the Link Layer will be investigated. In summary, this work-package will focus on the design, development and evaluation of an advanced Link layer that will support the transport of IP packets over a MC-CDMA platform, for the scenarios defined in D1.1[1]. In particular, it will investigate Dynamic Channel Allocation (DCA) to provide efficient resource allocation in a dynamic system environment, and into radio resource management (RRM) to allocate resources and maintain link quality in a dynamic cellular system. Moreover, WP4 will aim to design and specify a generic IP convergence layer that will provide support to the evolution of future all IP-core networks, so as to provide a degree of transparency between the Network and the Link Layer in line with the IP design philosophy. 1.2 System Level Design Methodology To evaluate the impact and performance of MC-CDMA on system level, we need to treat the IP convergence layer independently of the system level part. In addition, it is not the objective of this project to study Layer 3 performance, but to study the interface between layer 2 and 3. At layer 2, the focus is on the design of the radio resource management algorithms, and dynamic channel allocation. Radio resource management algorithms are common to wireless communication systems and are responsible for maintaining link quality, whilst dynamic channel allocation will provide continuous QoS for the service classes defined in D1.3[2], and in addition will maximize the use of the spectral resources. The technical annex explicitly dictates that there is a need to assess the performance of a MC-CDMA system, therefore these two entities that directly determine system capacity will be designed and optimized within an evaluation tool. The purpose of this deliverable is to provide a detailed specification of the evaluation tool, using an object orientated design methodology. In accordance with the annex, it will split up the development stage into three main design phases: a reference stage for validating the key software modules of the evaluation tool, an intermediate stage to provide benchmark performance curves of the system and an advanced stage that will integrate the advanced RRM algorithms. The assumptions of the simulator at each stage will be outlined, and followed by a description of the simulator object and interfaces. 1.3 IP Design Approach WP4 will study the interaction between the network layer, and the link layer. It will consider how IP packets can be handled efficiently at the MAC layer to provide seamless transport of IP packets over a MC-CDMA interface. The design phase will assume a DiffServ router node, to provide QoS treatment to the IP packets, and Fixed Channel Allocation (FCA) of the transport channels. The main IP processing blocks will be identified, and an IP interface architecture will be proposed, and specified for both the uplink and downlink flows. These concepts will be further explored in section 4.

10 1.4 Overview of D4.1 This document will provide a detailed specification of the reference V.0 system level simulator for simulations on reference RRM algorithms. It will outline the MATRICE objectives, and how these translate to WP4 scenarios. The key building blocks are identified in terms of Link Layer components, which include the RRM blocks, RLC, and the MAC layer. WP4 will also consider the development of an IP interface, to provide connectivity to the all IP core network. A detailed specification of the evaluation tool is provided by section 3.4, in terms of three main entities, being the task management, results and problem domain. Moreover, issues such as mobility, channel modeling, RRM algorithm assumptions, and ARQ are discussed. A summary of the simulator specifications is provided by section 3.7. A definition of the reference RRM protocol is also given by section 3.5, in term of architecture, service states, and main functionality. It was decided to design the simulator using an OOA approach. Therefore the simulator specification is also expressed in terms of an object-oriented structure, where details are given about the objects in terms of their main member functions, data attributes and their interactions. The IP design methodology approach is given by section 4, where the main focus is on the IP interface design goals, and detail is given about the proposed interface architecture for both the uplink and downlink flow. Section 5 provides a discussion on the Link Level Interface, where the interface architecture is defined along with details on the functionality, and the interactions with the physical layer simulation chain. Finally, a conclusion is given in section 6, with an on overview of the future tasks to be performed on the intermediate and advanced simulator.

11 2 System Level Objectives In this chapter we define the MATRICE objectives and WP4 requirements. The UTRA core network is shown, and we define how this evolves to the MATRICE core network. Moreover, the impact of an all IP network on the Link layer requirements is revealed. The research objectives at the IP interface layer are developed, and it is made clear that there is a need to define the control and user plane protocols for the efficient transport of IP over the air interface. 2.1 System Level Scenario An initial starting point is to specify the type of radio access network for MATRICE, and its attachment to the core network. As stated in D1.1 [1], the MATRICE project will adopt an IP perspective of the core network, to allow interoperability between different wireless architectures and to allow flexibility for the deployment of new services. It has been foreseen that a DiffServ approach will dominate the manner in which the network resources are allocated to the users. Taking this predefined notion into account, the core network can be represented by Figure 1. All IP-CORE Network SGSN DiffServ ROUTER DiffServ ROUTER DiffServ ROUTER RNC MATRICE RNC MATRICE RNC MATRICE RNC Vertical Handover Hard handover by MIP and TCP/IPv6 Intra-domain handover Soft and Hard handover handled RNC Inter-domain handover Hard handover handled by CIP, and TCP/IPv6 Figure 1: Conceptual MATRICE RAN architecture This approach fits in within the general perspective of a B3G system, and agrees closely with the proposed architecture followed by the IST project Evolute [3] or Moby Dick [4]. At the current moment there is no clear definition of a beyond 3G system, although there is common conceptual agreement on the philosophy of what it might evolve to be. The following section is a description of current trends in Network Layer Design currently pursued by the IETF (Internet Engineering Task Force), and their impact on MATRICE.

12 2.1.1 System Level requirements from Layer Mobility Mobility issues have been solved at the IP layer in order to hide its implications on the application level, thus adhering to the original design principles of IP. This implies that the base stations will be IP routers, with specific plug-in hardware to provide connectivity to the air interface. For macro-mobility, Mobile IP is a strong candidate, as it the protocol currently targeted as future standard, although several possible variants and associated problems are still under discussion. A stern test for its suitability will be its early deployment in 3GPP2 [5]. Although SIP is another strong candidate as it becomes integral part of Release 5 of 3GPP, and gets built into operating systems (e.g. Windows XP), this operates at a different network layer level. Micromobility within the radio access domain, can be considered as two problems, handover management (to provide seamless handover to the user) and path updates ( which addresses the issue of packet delivery to the mobile after handover to a new access router). Per-host forwarding solutions is likely to be considered for path updates, being the most IP purist approach, and are being integrated in Mobile-IP development. From a MATRICE perspective, we need to investigate how we can provide support to these types of handover at the MAC layer, perhaps in the form of providing signaling to Layer for proactive handovers or for using context-aware handovers. This definition will evolve throughout the duration of WP QoS provisioning In MATRICE we will have services with different QoS requirements. This means that the network will also need to provide some preferential treatment to specific IP flows to provide end-to end QoS. The requirements for QoS support led to active research into Differentiated services (DifServ) and Integrated services (IntServ). The Integrated services approach provides guaranteed QoS based on treatment of the traffic on a per flow basis. This comes at the expense of extra complexity in router call admission control and scheduling, and the need to use a signaling protocol, RSVP (Resource reservation protocol), to reserve the resources at the router beforehand. However, this reservation has to be continuously refreshed. This leads to extra network overhead reducing the network efficiency and capacity. In contrast, DiffServ does not reserve the resources, but marks the packets with a priority code, to be further handled on a per hop basis. This technique has its drawbacks, as it cannot directly provide a hard guarantee on the QoS, but provides preferential treatment only to data in the network. In MATRICE, we plan to develop a the wireless link that supports the DiffServ marking schemes, and using this signaling to set maximum delays, allocated from the delay budget to the wireless link. Therefore this means that a good mapping has to exist between the QoS definition at the IP layer, and at the MAC layer, so that the wireless link can provide support without exceeding the scheduled delay budget. The IP layer also needs to have a good understanding of the link layer scheduler, for minimization of the scheduling delay. In summary, as QoS in introduced into future networks, an attempt must be made to support this over the wireless link, hence the need for support functionality at the MAC layer and to interoperate with the core network IP transport The concept of integrating a RAN to an all IP network, is a new concept and reflects a departure from the current interface technology being considered by UMTS. Realized in UMTS R3 (release 99), the UTRAN was defined integrated to a GSM phase 2 core network. The core network basically consisted of known GSM components such as the Mobile Switching Centre (MSC), Home location Register (HLR), and Visitor Location register (VLR), but with added 3G functionality. This UMTS core network, is effectively considered to have two domains, for circuit switched, and packet switched services, each separated by their respective interfaces.

13 UMTS CORE NETWORK VLR MSC GMSC PSTN/ISDN Iu-CS SGSN SS7 Network HLR Iu-ur Iu-PS GGSN IP backbone network IP PDN UTRAN Figure 2: UMTS architecture In MATRICE, the MATRICE network will be similar to the architecture defined for an ISP provider in that it will be responsible for its own AAA security activities. The network will be packet switched, and the UMTS core network will merge in definition to that of Internet systems. This minimizes the complexity of the system design, and the signalling overhead for connections, as well as maximising the flexibility of the system to accommodate different communication systems. In this project, we will consider the transport of IP packets over the air-interface, which will motivate research into the user plane architecture and protocols to support efficient packet transfer. 2.2 Conclusion The conceptual system level scenario is given by Figure 1. In addition, it defines the scope of the MATRICE project. To provide seamless interoperability. To develop an IP interface protocol to support layer 3 handover for generic mobility protocols, and a protocol to support layer 2 handover between cells. To contemplate a DiffServ QoS mechanism at Layer 3. To develop a protocol to support QoS context transfer between layer 2 &3. This will translate to QoS support based on the service classes defined in D1.1 To define an IP interface architecture and protocol to support the data transfer of IP packets over a MC-CDMA air interface. To provide radio spectral efficiency in the presence of internet and real time traffic. This will be handled by DRA.

14 To undertake a feasibility study of MC-CDMA technology at system level by considering dynamic type simulations. To satisfy these requirements, a dynamic evaluation tool will be developed that will integrate RRM and DRA entities to evaluate system capacity. In addition, a Link Level Interface will be developed in close collaboration with WP3, and integrated into the simulator to provide physical layer performance data. Moreover, the impact requirement from layer 3 will be pursued by a separate study on the design and specification of an IP convergence layer. Section3 will be dedicated to the specification of the reference level simulator, whilst the IP aspect will be treated by section 4.

15 3 System level Evaluation Tool Definition 3.1 Introduction In this section, the design stages and the specifications of the dynamic system level simulator are given. The design stages identify the main objects in the evaluation tool, from high-level requirements down to detailed specification. The objects that are considered are the functions that are part of the Link Layer structure, and blocks that allow user mobility to simulate the real environment. The reference simulator is designed using a C++ design methodology approach. Therefore a description of the object orientated structure of the simulator, and a definition of the specific objects and their interfaces are given. 3.2 Layered Structure Definition The high level requirements of the evaluation tool are to measure system capacity and spectral efficiency, the evaluation criteria for which is given by D1.3 [2]. However, the design of the reference simulator must be sufficiently complete, so as to provide sufficient modeling accuracy, whilst still keeping simulation time and excess complexity to a minimum. The basic conceptual model for the evaluation tool will be based on the structure given by Figure 3. NETWORK LAYER IP CONVERGENCE WP4 LINK LAYER LINK LEVEL INTERFACE PHYSICAL LAYER Figure 3: Layered structure model It identifies three main components: Link layer that defines the Radio Resource Management (RRM) to maintain link quality, Radio Link Control (RLC) that provides re-transmissions to keep the Packet Error Rate (PER) at the desired level, and the Medium Access Control (MAC) layer, that will define the resource allocation. IP convergence layer that support connectivity to the IP layer, to provide the transport of IP packets over the MC-CDMA interface. Link Level Interface that provides receiver performance data based on the modes of operation defined in the Link Layer.

16 A complete simulator in the sense that it integrates the physical layer chain and the IP layer into the same simulation platform, to provide a true adaptive solution with time is not practical. A Link Level Interface will be developed to provide the physical layer statistics, for the given modes of operation defined by the scenarios. Currently there are two types of simulator structures: the dynamic (time based) simulator and the Monte Carlo The dynamic simulator can support user mobility, measurement modeling and algorithmic time scheduling, although there is a strong tradeoff between sampling frequency and simulation time. The Monte Carlo approach involves taking snapshots of the system state, with the mobiles distributed throughout the system, thus resulting in low complexity. To obtain a good statistical analysis, would require a large number of shots, for different mobile positions and functional states. The combination of both approaches can provide complementary viewpoints of the system performance in terms of capacity, coverage, macrodiversity zones, with interference statistics. However, a dynamic simulator is more appropriate to model algorithmic performance, and to provide a network level QoS analysis. Therefore we consider the design and specification of a dynamic system level simulator that will support user mobility integrating the channel scenarios and services defined in D1.1[1]. In addition IP interface architecture will be investigated and specified. The rest of this chapter will consider the specification of the reference simulator. It will focus on the definition of the key simulator blocks, and the definition of the control plane protocols that dictates the configuration of the Radio Resource Connection (RRC). 3.3 Link Layer Technology The Link Layer will consider the design of the radio resource management algorithms, which includes Power control (PC), Call Admission Control (CAC), and Handover (HO). In particular DCA will be studied at the MAC layer. Figure 4 provides a conceptual insight into the Link Layer technology. Control HO PC RRC CAC Logical Channels Loading Time Slots Measurements MAC DCA Frequency Transport Channels Carriers Dynamic Channel Allocation: LAYER 1: WP3 The capacity of a MC-CDMA system is time varying and the foreseen traffic is bursty in nature. The objectives of MATRICE at the MAC layer is to investigate Dynamic Channel Allocation, so as to handle dynamic traffic QoS requirements and achieve high spectrum utilization. Figure 4: Link layer technology The Link layer can typically provide the following services: RRC: The combination of HO, PC and CAC are used to control access to the radio resources and to maintain radio link quality. RLC: Controls the QoS of the radio link. The Link control is responsible for keeping the PER at the desired level. Upper layers will provide the Maximum Delay that the radio link can support before the packet session is dropped. The QoS setting is negotiated by the network, and the quality of the link is controlled by ARQ (Automatic Repeat Request) mechanism, that retransmit payload

17 units (PU) that are in error. The maximum number of retransmissions is determined by the service type. However, it is foreseen that an unacknowledged mode will be a prerequisite for delay sensitive services, where the PUs are transmitted without acknowledgement. Typical functions may include: Segmentation and reassembly of variable length PDUs. The RLC Service Data Unit (SDU) will contain several PU units. For a variable rate service, the PU size is set to the minimum bit rate, so that for the peak bit rate, an integer multiple of PU packets will be transmitted for a given transit interval. Concatenation and padding In sequence delivery Flow control Sequence number check Ciphering MAC: Its main function is to provide the mapping between the logical and transport channels, based on a decision criterion taken in the RRC layer. In addition, a typical MAC layer would carry out the following functionality: Transport Channel Selection Multiplexing several logical channel to a common transport channel, Flow control between buffers Priority Scheduling. The MAC layer decides when to place a Protocol Data Unit (PDU) onto Layer 1. It will also provide information on the transport format identifier type. Measurement and Reporting: The system level continuously monitors the loading conditions, and the resources available so as to provide input to the RRC through a defined interface. This information will dictate how the RRC controls the dynamic behavior of the MAC layer. The measurement of WP3 parameters will be provided through a link level interface. Having identified the Link Layer technology, the next design stage is to investigate the scope of the evaluation tool, to identify which key blocks and assumptions are required to support the evaluation of the radio resource management protocols and DCA at the MAC layer. 3.4 Simulator Specifications Therefore the main blocks of interest in the system level architecture have been defined by Figure 5. The main blocks that are common to a packet switched system level simulator are grouped into specific categories, the terminology of these groups map to specific abstract functional blocks of the simulator architecture. This classification supports a C++ object orientated approach to the development stage.

18 TASK MANAGEMENT DOMAIN EVENT SCHEDULER TASK COORDINATOR HUMAN INTERACTION DOMAIN INITIALISATION RESULTS 2 1 RESULTS DOMAIN RESULTS DATABASE 4 PROBLEM DOMAIN MOBILITY CALL ADMISSION HANDOVER POWER CONTROL DYNAMIC CHANNEL ALLOCATION QoS MEASURE MOBILITY MODEL SERVICE QUEUE TRAFFIC MODEL PROPAGATION MODULE SIMULATOR MAP (WRAP AROUND) 3 Figure 5: Simulator structure For each domain, the following assumptions and specifications have been taken Task Management Domain Task Manager Task Manager is responsible for overall coordination of the system. On each time step, it will carry out CAC functionality, that includes checking for new users, closed loop power control, check for handover, mobility update, dynamic channel allocation and QoS measurement. These functions are shown in the problem domain subject area, whilst specific modules/objects are shown by the pink colored boxes. Any results emanating from the problem domain will be placed in the results domain database. In addition, it may support a Human Interface Event scheduler The scheduler mechanism will generate the arrival process of the users, according to a Poisson arrival process. This will be done at simulator initialization. The function will check the number of arrivals at the current time step Human Interaction Domain This component forms the GUI of the system. It allows the user easy access to an initialization file to update the input data, and provide access to the required results.

19 3.4.3 Problem Domain CAC A description of the reference CAC, and their assumptions is defined in D4.2 [6]. In this section we treat the CAC to be a black box, and consider its interaction with the rest of the simulator. This simulator reflects a packet switched service, where all the services are data, in line with the all-ip core network scenario. The call admission process will not only deal with the admission part, but plays the following role. On every discrete time step, the CAC function invokes the event scheduler that provides information on the number of users that have arrived into the system. These events will have been predefined in the initialization stage, along with the mobile identifier number and the service type. The service identifier invokes the appropriate traffic model that provides statistics of the packet session; this would include the number of packet calls per session, reading time between packet calls, number of packets within a packet call, time between packets within a packet call, and the packet size. This information is predetermined for the entire packet session, and stored in a matrix. A buffer is created that stores information about the instantaneous bit rate, the average bit rate, and the amount of current delay associated with the specific service. Each buffer is part of the service that contains entries for each service admitted into the system that is ordered in terms of priority. The CAC function, will deal with the highest priority service first, to see whether it will either, accept, reject or delay the service. If it is accepted, then it will invoke the packet scheduler to allocate the resources. However, if the delay counter has exceeded the maximum tolerated delay for this service, then it will reject and update the results database. Finally, if it is delayed, then the delay counter will increment accordingly. After the highest priority service has been checked, it will scrutinize the next highest priority service on the list Scheduling The scheduler decides how to allocate the appropriate resources, based on the service type, the amount of data, the load on the common and shared channels, the current loading in the cell and the radio performance of each type of transport channel. In WCDMA, there three types of scheduling are defined: Time division scheduling: This is based on the concept of several users sharing the same transport channel, in time. Thus each user will be allocated the entire bandwidth for a short period of time, each sharing the same code. This technique provides code efficiency, and is more suited for bursty traffic, and in addition it can provide good link performance due to the high data rate. This scheme is usually used with shared channels. This type of allocation will provide high interference variations with time, thus having an impact on the real time services. Code Division scheduling: Each user is given bandwidth on demand, by allocating user different codes. The scheme is associated with dedicated channels, and low bit rate users. It will provide an initial delay on set-up, and can lead to more predictable interference loading. The efficiency of this type of scheduling is dependant on the accurate estimate of the average bit rate. A poor estimate will lead to inefficient use of the spectrum, thus a dynamic allocation scheme is desirable. Power based scheduling: This will allocate resources based on the user location. It will allocate low bit rates to user on the fringe area, and higher bit rates to those nearer the base station. This scheme will have direct improvement on the average downlink capacity. Although, all the schemes can provide good performance in different conditions, there is no one scheme that can be considered to be the best candidate, and typically a combination of scheduling techniques are used to provide overall performance gain. The scheduler in the reference simulator will be code division, although it can also consider allocating resources both in time and frequency. Still, only dedicated transport channels will be considered in the reference stage, and channel signaling time set-up will be implicitly assumed, but will not be considered in the overall delay associated with dropping a packet session.

20 Power Control Slow power control will be modeled, to maintain link quality. The algorithmic details of power control are given in D4.2 [6]. If perfect fast power control is to be modeled, then we have to take the following assumptions regarding the power control function: - Fixed TDD switching point - Fixed frame period T_frame - Fixed channel allocation - Frame period is very small compared to the fast fading coherence time. - The fast fading coherence time is much lower than the shadowing and the path loss coherence time. - Attention must be paid to the fact that we are dealing with packet services. The packet session is bursty with periods of activities. In a period of activity a number of packets are transmitted with a variable inter-arrival time between packets. We assume these periods of activities correspond to a continuous use of the resource during a time that is much larger than the fast fading coherence time. We assume that the interference remains constant throughout the time step duration. These assumptions allows us to assume that the path loss, shadowing and the load activity have a more static variation than the fast fading, which allow us to model the fast power control in a more simplified manner. Indeed, we do not need to determine the real period of fast power control, nor to simulate it. We can model the effect of fast power control by simulating a slow power control that adapts to the average transmit power, to the instantaneous shadowing, path loss and load. The effect of the fast power control can taken into account at the link level interface by improved SIR-to-PER performance, and by the effect of the average power rise. The simulator sampling time will be at the slow power control frequency, which will be chosen to be at the time coherence of the slow fading channel, which can be used in all the predefined channel environments Handover Handover is common to all dynamic system level simulators, and required to maintain link quality at the cell boundaries. Hard-handover will be assumed, as soft-handover is not feasible given the TDD structure of the duplex mode, and delay sensitive services. In the reference simulator, the UMTS handover algorithm will be adopted where the number of base stations in the active set will be set to one. Only Layer 2 Handover will be considered Mobility Model Typical models will be employed to model mobile movement in indoor, outdoor urban, and sub-urban environments. Parameters associated with mobility include speed, probability to change speed at position update, probability to change direction, and the decorrelation length. This latter parameter will dictate the simulator time interval between mobility updates. A detailed specification is given by D1.3 [2] Simulator Map This provides a description of the cellular map, which includes the cell descriptions, base station locations, and the manner in which it will model mobile movement at the system boundaries. A wrap

21 around model will be used, instead of modeling mobile movement bouncing of the edges of the outercells. This means that the mobile may migrate off the edge of the system boundary and, emerge on the opposite side, in a wrap around fashion ARQ Simple ARQ will be employed for non-real time services. It is assumed that variable IP packet sizes are translated to fixed packet sizes in the RLC layer, through segmentation, concatenation and padding. However, variable RLC block size will not be modeled in the reference simulator. When the link quality is below the target level, the QoS block will decide whether to drop any packets based on the average SIR value measurement and target value. Packets that are assumed to arrive in error, will be dropped and retransmitted. The retransmission is implicitly assumed, and the delay counter associated with the user queue will be incremented accordingly. We assume that many packets can arrive within the time interval. If the SIR is below the target value, a PER model will suggest whether the specific packet is in error QoS measure This module is responsible for analysing the link quality for each transport channel. If the quality deteriorates below a certain level, then it will take the appropriate action. It will increment the service delay counter, and will drop the packet session if the maximum delay has been exceeded. The detailed definition of the dropping criteria will be given in D Service Queue All services are packet based, and defined by the QoS context, that will include information such as instantaneous bit rate, average bit rate and current delay, and maximum tolerated delay. All new incoming users will be assigned a priority value, and then placed in the queue. This service queue will list all the mobile that are waiting to be served, as well as all users that have already been allocated a transport channel. The QoS Control block will look at this table to see whether any user has breached the QoS, and drop it from the system Dynamic Channel Allocation In the reference simulator Fixed Channel Allocation (FCA) will consider as the initial starting point. The DCA algorithm can be considered supplementary that will provide extra performance, but is not a pivotal element in the simulator. It is important to validate the basic simulator architecture at the earliest design stage, and to provide some benchmark performance curves. In this way, the immediate improvement given by DCA can be noticed at the intermediate design stage, and verified. FCA assumes that once the appropriate service bit rate has been allocated, and the scheduler has mapped the logical channel to the best resource unit available, the allocation will remain fixed throughout the duration of the simulator. Hence, it is important that the average bit rate is estimated accurately, so as to preserve spectral efficiency. The need for DCA arises when changes either in the traffic, or channel conditions lead to under occupancy and a reduction in the QoS Propagation Module The module will model path loss, slow fading. Channel models for indoor environments, outdoor urban and rural environments will be provided Link Level Interface To provide an adaptive solution, the system level platform must be integrated into the Link Level platform. This solution is not efficient, and there is a direct trade-off between modeling accuracy, complexity and simulation time. Therefore, we suggest an approach where the simulator modes of

22 operations are not only restricted to the defined service classes, and scenarios, but can be defined on line. The Link Level Interface will provide the look-up tables for the system level simulations based on the average value interface approach, but the scenarios can be defined beforehand. An interface translates the system level parameters to the appropriate transport format parameters to simulate the Link Level chain, resulting in a table with SIR v PER for a specific simulation environment. This is a tentative solution to the adaptivity concept Access and Duplex Technique The access technique will be TDD MC-CDMA. Thus implicitly it can support FDMA MC-CDMA, TDMA MC-CDMA, and the combination of both. It will support FDD MC-CDMA if the relevant look-up tables are updated to take into account the dual frequency bands Services The MATRICE system will support the QoS classes defined in table 1 Indoor@3km/h Urban Vehicular@60km/h Rural Vehicular@60km/h DL UL DL UL DL UL BER=10-6 Delay=50ms PBR= 2Mbps GBR = 384kbps PBR= 2Mbps GBR= 384kbps PBR= 2Mbps GBR= 384kbps PBR= 2Mbps GBR= 384kbps PBR= 2Mps GBR= 384kbps PBR= 2Mbps GBR= 384kbps BER=10-6 Delay=300ms PBR= GBR= 10Mbps 2Mbps PBR= 2Mbps GBR= 384kbps PBR= 10Mbps GBR= 2Mbps PBR= 2Mbps GBR= 384kbps PBR= 10Mbps GBR= 2Mbps PBR= 2Mbps GBR= 384kbps BER=10-6 PBR= 10Mbps PBR= 2Mbps PBR= 10Mbps PBR= 10Mbps PBR= 10Mbps PBR= 2Mbps no delay BER=10-6 PBR= 10Mbps PBR= 10Mbps PBR= 10Mbps PBR= 10Mbps PBR= 10Mbps PBR= 10Mbps no delay Table 1: MATRICE QoS classes Mobiles The system will have the flexibility to support different mobile types, supported by the inheritance attribute C++ offers. Each mobile type will be defined by the following parameters: Antenna type- antenna type will be assumed to be omni directional Maximum transit power- the maximum transmit power the mobile can support. Mobile noise figure- the receiver sensitivity Power dynamic- the transmit power range the mobile can support between max. and min. Mobile Coordinate- each mobile is responsible for updating its coordinates, in terms of position and velocity. In the reference stage, it will be assumed that the same mobile type will be used for all the given scenarios.

23 Base Station As in the mobile case, the Base Station class is a template, which will support child objects with added functionality. The following generic template can be defined as: Antenna type - antenna type will be assumed to be omni directional Maximum transit power - the maximum transmit power the mobile can support. Base Station Noise Figure- the receiver sensitivity Power dynamic- the transmit power range the mobile can support between max. and min. Resource Unit Identifier: A 3-D coordinate provides a description of the frequency slot, time slot, and code number Signaling All signaling will be implicitly modeled, to reduce simulator processing overhead Transport Channels The transport channels reflect the available resources in the cell. Separate resources exist for both uplink and downlink. The capacity of the resource unit is to be determined in WP3, and is dependant on the receiver and frame structure that provide overhead, and on link quality simulations under different scenarios. But effectively, the output of WP3 will be a series of physical layer data rates, the minimum data rate matching the highest spreading factor employed. 3.5 Radio Resource Management Protocol. In the development of the system level simulator, not only is there a need to design and evaluate the RRM functions, but to provide a formal definition of the protocol. The intention is to develop this in parallel with the design of the simulator throughout the duration of WP4, the objective is to attain an intermediate and advanced description for D4.3, and D4.4. The main function of radio resource protocol is to control the set-up, release and the maintenance of a wireless connection. In this section, we provide an initial description of the reference RRC protocol, in particular emphasizing the conceptual RRC protocol architecture, service states and functions. The definition of the protocol will evolve in the intermediate and advanced stage of the system, taking into account implications from the IP layer. In this definition, we emphasize the quantities that need to be measured, and how to treat this information. In the reference stage we assume that QoS negociations for radio access bearer set-up have taken place, and that the RRC is only responsible for CAC and maintaining the link quality RRC Architecture The RRC layer architecture can be given by Figure 6.

24 RFE BMC-ctrl SAP PDCP-ctrl SAP DFE PNFE BCFE RLC-ctrl SAP MAC-ctrl SAP L1-ctrl SAP RLC SAPs ARQ-Mode Non ARQ Transparent Figure 6: RRC layer architecture The RLC architecture can be defined by four main components: DCFE: Dedicated Control Function entity that handles all the functions and signally corresponding to one UE. This corresponds to one SRNC having a specific DCFE for every RRC connection, in addition all messages can be sent in ARQ mode. PNFE: Paging and Notification Control Function Entity controls the paging of idle mode UEs, where there is typically at least on PCCH channel for every cell under the domain of the RNC. BCFE: Broadcast Control Function Entity is responsible for realizing system information broadcast. There is at least one BCFE for every cell under the domain of the RNC. The BCFE will usually use the BCCH of FACH logical channels and use transparent mode in the RLC. RFE: Routing Function Entity used for routing RRC messages between RLCs and to higher layer entities. It can be seen that that the RRC architecture can be based on a UMTS definition, as many of the principles in UTRAN can be conserved for a MATRICE system at the radio layer RRC Service States There are two main modes of operation: Idle and connected mode. The connected mode can be further expressed into more specific states that determine the kind of transport channels the UE uses. The transitions between the service states can be seen by Figure 7. Idle Mode Cell DCH Cell FACH Cell PCH URA PCH Connected Mode Figure 7: RRC service states

25 Idle mode: When the UE enters the system, it scans the current PLMN, it then goes on to define an appropriate cell, and tunes into the broadcast channel. In this manner, it may listen to the system state on a continuous basis. This procedure is known as cell camping. Once in idle mode, the UE remains in this mode until it receives a RRC message requesting connection. Cell DCH: In this mode, the UE is allocated a dedicated physical channel, and information about the UE is known by the serving RNC. The UE is continuously performing measurements, and sends reports to the RNC. An example of this is DCA, where the mobile is sending measurements about the SIR of the available downlink channels to the RNC, to evaluate the loading and consider a reallocation of resources. Cell FACH has no dedicated channels allocated. It is using the FACH and the RACH for sending small amounts of data and control messages. Moreover, it enters this mode for cell re-selection. It is continuously listening to the broadcast channel, when it enters a new cell, it sends a request to the RNC to update its cell entry in the table. A unique identifier in the RRC message will route the cell update message to the current RNC, if there is intra-domain handover. Cell PCH: This mode assumes the UE to be listening to the paging channel, and the broadcast channel, and therefore has minimal requirements on power consumption. The terminal may only be contacted by the paging channel. URA PCH : This state is similar to the Cell PCH, but does not carry out a cell update procedure after cell reselection. It doesn t inform the network about its current location, until it discovers that the UTRAN Registration number has changed. This can also be considered for MATRICE. Taking a higher level perspective, Figure 8 shows the service modes of future beyond 3G terminals. Camping on a MATRICE Cell MATRICE Connected Mode Idle Mode Tri State Camping on a UTRA Cell UTRAN Connected Mode Inter-system cell reselection Camping on a WLAN Cell WLAN Connected Mode Layer 2/3 Handover Figure 8: Service modes for Beyond 3G systems It is expected that a MATRICE terminal can be part of a future 4G system as defined in D1.1. The terminals are required to have inter-system handover support, so requirements are for a connected state for each of the entities of the all IP-core network, although WLAN, UTRAN and MATRICE connectivity are shown. In addition, the terminal may need to have reconfigurable properties, so that it can support the aforementioned systems at the same time, in the so call tristate connected mode.

26 In practice, the reference simulator will consider DCH mode, and idle mode is implicitly assumed. The event scheduler will decide when the mobile terminals become active, and enter into connected mode through call arrival, priority scheduling and call admission control. The reference model also assumes that a single system is modeled, and that intersystem handover does not occur. Cell camping in idle mode is also implicitly assumed. However, although Layer 3 handover will not be simulated, it will be treated as part of the study on the IP interface RRC Functions The main functions include: Control of Radio bearers, transport and physical channels: RRC functions include Layer 2 handover, Dynamic channel Allocation and closed loop power control. Establishment, maintenance and release of the RRC connection between the MATRICE RAN and the UE. This is defined as a RRC connection between the RRC and the UE, in addition to an Iu connection, the latter being configured in the IP convergence layer. There can always be one or zero connections between one UE and the MATRICE RAN. In UTRAN, the establishment invokes the CAC to discover whether it can allocate the resources to the service request, and sets up four signaling radio bearers, used for control and direct transfer messages, which are transmitted on the DCCH. The signaling may include configuration values and channel assignment parameters. A set-up signaling request is followed by a confirmation message by the contacted entity. In MATRICE, as we are assuming all packet services, new users may not necessarily be admitted to the system but placed on the queue; the highest priority service will be subjected to CAC. So a new user, may not be allocated resources initially, however will be instructed to wait until resources become available. This will have an impact on the signaling protocol design, as the terminal will not assume connected mode until a connection set-up is complete. However, all the signaling is implicitly assumed in the reference simulator design, in that an IP connection is set-up automatically and that the simulator keeps track of the UEs, in terms of their QoS requirements and the allocated resources. To support serving RNC tracking: a special message that is sent from the existing RNC to the updated serving RNC. The message contains state information and all the required parameters (RRC, RLC, MAC, PHY) needed to set up the UE context in the serving RNC, so as to make the RNC handover seamless. In MATRICE, the IP interface will need to support context transfer between routers, which will be treated as part of the mobility management support. Support for DL outer-loop power control Open Loop power control Cell broadcast service related functions Support for UE position update Cell selection and reselection in idle mode. The most suitable cell is chosen based on measurements taken at Layer 1, at the UE. Paging support: Needs to handle paging signals, that are transmitted on the PCCH. If the call originates from the network side, it will also be supported by the IP interface, as well as the RRC function. Security for signaling messages. In UTRAN, it provides ciphering and integrity protection between the UE and the radio access network, and to invoke the change of ciphering and integrity keys during the connection. Broadcast of system information. System information conceptually relates to specific states and parameters from the core network, RRC, and the node B. This information is usually sent on the BCCH logical channel, which is usually mapped to the BCH, and FACH.