• 沒有找到結果。

Chapter 2 Background

2.2 Multimedia traffic report systems [18]

The Intelligent Transportation System (ITS) attracts great attention in recent years.

Along with wireless technologies and related software, the ITS can integrate vehicle communications with many applications like traffic surveillance, emergency notification and navigations. The multimedia traffic report system is a part of ITS. Its main function is to provide traffic conditions for monitoring usage or further analysis.

The traffic data collection of traditional traffic report systems is based on road-side cameras, while now we can gather traffic data directly via sensors or devices equipped on cars. Because of the diversity of on-car devices, the traffic data received contain various types; for example, the event data recorder (EDR) and camera can capture video or images on roads, the e-compass and GPS (global position system) tracker can provide directions and positions of cars.

These traffic data gathering from on-car devices or sensors must be transmitted to a back-end server on the Internet through wireless networks. Due to the characteristic of limited radio resources and numerous devices, the management of vehicular wireless networks is an important aspect in the multimedia traffic report systems. The integration of vehicular networks and LTE can leverage the M2M (machine-to-machine) technology [20]. In order to acquire plenty, diverse traffic data

under certain wireless network environment, a proper resources management mechanism is required.

Chapter 3

Resource Management Issues and Problem Statement

In this chapter, we introduce potential problems in multimedia traffic report systems and provide a formal problem statement for resource management issues. To receive the most diverse and plentiful traffic data from enormous number of devices, we have to decide which of them should transmit to meet our needs. In addition, due to the transmission is under wireless environments, checking radio channel quality can help us to improve resources utilization efficiency. Here we focus on several aspects to discuss the resource management issues:

3.1 Homogeneous traffic data and incomplete coverage

The homogeneous traffic data and incomplete coverage problems could happen if we do not consider location information and capabilities of on-car devices. In the multimedia traffic report systems, large amounts of traffic data may come from any places in different data types or data formats. If devices locations and capabilities are ignored when doing scheduling, we may receive traffic data from the same place or all the traffic data are in the same type.

3.2 Duplicated traffic data

The duplicated traffic data issue is a severe case of above-mentioned problem. If any of two traffic data entries are from an identical location and in the same data type, we consider them are “duplicated traffic data”. If many duplications are received in multimedia traffic report systems, there must be a portion of resources are wasted, because we use much more resources to transmit the same traffic data. We will describe duplication check and grouping in chapter 5.

3.3 Poor channel quality

Since the data transmission of multimedia traffic report systems is under wireless networks, the concerns of radio channel quality and resources limitation become more important than those in wired networks. The geographical landscape, vehicular scenario and car speed can affect channel quality, and poor channel quality may cause transmission failures, and lead to data impairment or video distortion. To prevent this kind of problems, the AMC (adaptive modulation and coding) in LTE will adjust the modulation and coding scheme to suit the current wireless environment. But this may result in resource wasting because it will allocate more radio resources for a sender to transmit the same quantity of data when its channel quality is poor. Moreover, the number of served sensors/devices will reduce due to limited resources.

3.4 Problem statement

In the design of traffic report system, the main objective is to improve the completeness, diversity and overall traffic data value of received traffic data under certain environment constraints. In the following, we describe the constraints, variables and performance metrics in detail, and related definitions and notations are shown in Table 2.

3.4.1 Constraints of resource management

There are many limitations affecting the resource management procedure. is the CQI (channel quality indicator) of the ith UE, is the guaranteed bitrate that is required by the ith sensor/device, and represents the importance degrees corresponding to vehicle type, sensor/device type and location of the ith sensor/device, respectively. The importance degrees are used to compute the traffic data value of each sensor/device for scheduling resources.

3.4.2 Variables for resource scheduling

In the proposed resource management mechanism, we schedule resources according to two variables, and . is the traffic data value provided by the

𝐼𝑖 CQI (Channel quality indicator) of the ith UE 𝑏𝑖 Guaranteed bitrate of the ith sensor/device 𝑆𝑁 Number of sensors/devices

𝐿𝐵𝑁 Number of location blocks

𝐷𝑎𝑡𝑎𝑁 Number of received traffic data entries 𝐷𝑢𝑝𝑁 Number of duplicated traffic data entries

𝑉𝑖 Traffic data value of the ith sensor/device

𝑅𝐵𝑖 Required resource blocks (RBs) of the ith sensor/device 𝑑𝑖𝑣 Vehicle importance degree of the ith sensor/device 𝑑𝑖𝑠 Sensor/device importance degree of the ith sensor/device 𝑑𝑖𝑙 Location importance degree of the ith sensor/device

3.4.3 Performance metrics

In the traffic report system, its performance can be evaluated by location coverage, duplication ratio and overall traffic data value. The performance metrics to evaluate our design are shown below: one of our objectives. The definition of duplication ratio is:

Where represents the total number of received traffic data entries, and is the total number of duplicated data entries.

 Overall traffic data value:

In our design, each vehicle, sensor/device and location has its own importance degree, which indicates the traffic data value that it can provide. Therefore, when

allocating resources, we have to consider the traffic data value of each sensor/device.

The definition of overall traffic data value S is:

{

Where value represents the overall value of the traffic data we obtained. means the traffic data value provided by the th sensor/device if we allocate resources to the th sensor/device. is the number of sensors/devices.

Chapter 4

Related Work

The researches related to resource management problems in LTE can be roughly classified into two types: (1) non application-aware (2) application-aware mechanisms.

Figure 2 is the classification tree of related work. In addition, application-aware resource management mechanisms can be applied either to mixed-traffic, which includes various types of data, or just single-type traffic. Our work is dedicated to application-aware resource management for mixed-traffic over LTE, and the application we concerned is the traffic report system. Follows are brief review of related work:

R. Kwan et al. [4] proposed an uplink resource management algorithm based on PF Figure 2 The classification tree of related works.

(proportional fair) basis. The authors focused on the multiuser fairness problem of resource scheduling strategies, and they also provided a suboptimal solution with low complexity. By leveraging their PF scheduler, the variations of user bit rates can be effectively reduced compared to Max-Rate scheduler.

I. C. Wong et al. [3] presented a resource management algorithm for uplink LTE.

They modeled the resource allocation problem as a pure binary-integer program, and provided a greedy-based heuristic approach with low complexity. Their simulation results indicate that the spectrum efficiency can be improved by 50% using their algorithm while using the optimal algorithm can be improved by 100%.

H. Luo et al. [21] presented a cross-layer weighted-RR (round robin) QoS-aware resource management solution for downlink LTE. They focused on the application layer QoS requirements to optimize the video transmission. In their research, they jointly concern channel quality, delay-constraints and user fairness among all users against each resource block, and further dynamically adjust the MCS (modulation and coding scheme) and encoding parameters to achieve better video quality. The performance evaluation results show that the video’s PSNR is significantly improved by adopting their method.

L. Li et al. [15] dedicated to the mapping function between QoS class identifier (QCI) to Diffserv Code Point (DSCP) (QCI/DSCP mapping), which can extend the QoS provision from the bearer-level to the transport-level. The authors also presented a system level performance management tool for end-to-end QoS monitoring.

A. Gotsis et al. [2] introduced the challenges and solutions of M2M scheduling over LTE. The authors pointed out main issues when M2M comes to LTE: numerous devices, sparse transmission, and widely range of applications. These issues lead to signaling overhead in the control plane, and the diverse QoS requirements are hard to

granularity of scheduling. The idea of group-based scheduling is to schedule resources among device-groups rather than devices themselves, while time granularity of scheduling focused on the scheduling time period.

El Essaili A. et al. [1] proposed a QoE-driven optimistic resource allocation method for LTE uplink. They formulize the Quality of Experience (QoE) value, by using the mean opinion score (MOS) function to determine the quality of user experience. This research focuses on the popularity of user generated video contents transmitted over LTE radio networks. The popularity is used to rank the video contents, while the network control entity (e.g., eNodeB) can schedule resources among content producers.

S. N. K. Marwat et al. [5] proposed a scheduling algorithm based on weighted-PF on multimedia applications, called BQA (bandwidth and QoS-aware scheduler). They concern throughput, delay, fairness and the different QoS requirements of each traffic types, and allocate resources based on weighted values calculated from the above parameters. The results show that with the help of QoS weights, each traffic bearer can attain better performance.

In our research, we focus on the end-to-end resource management for the multimedia traffic reporting system over LTE, and the objective is to gather more data in a specific area. The qualitative comparison among our work and related work is shown in Table 3. The main feature of our work is that we allocate resources not only by channel availability but by information and location importance degrees.

Table 3 The qualitative comparison of existing resource management mechanisms and the proposed QoS-MTRS.

Classification Main Issue Approach

Non application-aware Uplink radio

Chapter 5

QoS-MTRS: QoS-aware Resource Management for Multimedia Traffic Report Systems

In this chapter, we introduce our proposed QoS-aware resource management for multimedia traffic report systems (QoS-MTRS) in detail. QoS-MTRS is an end-to-end resource management mechanism over LTE. It leverages the functions of EPS bearer and policy controller to support the QoS provisioning. The resource management mechanism in our design is used to guarantee the performance of multimedia traffic report systems.

To derive the most complete and valuable traffic data under certain channel conditions and limited resources, the proposed QoS-MTRS acts as a policy controller in the LTE packet core to make all the allocating decisions. Its responsibility is to decide how bandwidth resources and QoS parameters are reserved to each bearer.

The overall system flowchart of QoS-MTRS is shown in Figure 3. In our design approach, there are two important functional modules, information importance analysis and channel availability check, which are described in section 5.1 and 5.2:

5.1 Information importance analysis

In this module, we analyze information importance of all the traffic data and check for traffic data duplications. First, we have to compute the traffic data value of every on-car sensor/device. Because of limited channel resources, choosing the most worthwhile information to transmit can prevent resource wasting. There are three variables can affect of each sensor/device, which are vehicle type, sensor/device type, and location. For example, a video traffic data from a police car at a crossroad may be more urgent than an audio one from a household vehicle at an alley. Therefore, we compute of all the sensors/devices for later sorting.

Figure 3 The overall system flowchart of QoS-MTRS.

Another issue for this module is the traffic data duplication problem. For instance, vehicles at the same location may report identical traffic data at a certain time if they are equipped similar sensors/devices. Hence, checking whether there are duplicated traffic data and removing them is required in saving resources.

5.2 Channel availability check

When allocating resources, it is necessary to make sure radio channel quality and the transmission environment are suitable for sending data. The CQI must be measured and concerned to prevent transmission failures and resource wasting. For example, if a vehicle is under poor channel condition, it may be allocated more radio resources to transmit its data because the data rate has been reduced due to the poor channel. Therefore, checking CQI and derive the required resources is necessary for efficient resources management.

5.3 EPS bearer establishment and QoS parameter setting

When a vehicle enters the LTE network, it must establish an EPS bearer for IP network services. The default EPS bearer is used to support basic transmission and signaling control for dedicated EPS bearer establishment. The dedicated EPS bearer is the level of granularity for bearer-level QoS control [9], which indicates the bandwidth resource allocation in the form of multiple QoS parameters, including QCI, GBR and MBR. In our design, the resource manager acts as a policy controller to manage the resource arrangements and the QoS parameter settings.

5.4 Design approach

In our design, there are five stages in the whole process, and here we describe each stage in detail:

5.4.1 Deriving pre-defined QoS requirements

In the beginning, resource manager will derive the QoS requirements from back-end database for later usages. These requirements include importance degree and guaranteed bitrate of each vehicle type, sensor/device type, and location. The importance degrees are regarded as given values because they are derived from numerous statistics data or based on the needs of service providers. There are three types of importance degrees:

 Importance degree of vehicles:

Traffic data reported by different vehicle types may have different importance degrees. For example, the importance degree of a police car is higher than that of a household vehicle.

 Importance degree of sensors/devices:

The type and ability of each sensor/device can cause the divergence of reported traffic data. For instance, video data can provide better understanding of multimedia traffic conditions than text data, and the resolution of a video affects the quality of the reported data.

 Importance degree of locations:

For traffic report system, some locations like crossroads need more attention for safety monitoring. We partition a map into several blocks as shown in Figure 4, and each block takes a given importance degree. Note that the map image is from the Taipei e-Map [22].

5.4.2 Vehicle connection establishment

After deriving all the needed QoS requirements, the resource manager waits for vehicle connection requests. When vehicles enter LTE network and try to establish default EPS bearers, the information of sensors/devices equipped on these vehicles will be transmitted as request payloads. These sensors/devices information will be sent to the resource manager for determining how resources will be allocated.

5.4.3 Information importance analysis

In this stage, all the sensor/device information received by resource manager will be processed to compute their traffic data values and determine if these traffic data are duplicated or not. The details are as follows:

 Deriving sensor/device information

After the vehicle connection establishment stage, the resource manager will receive all the vehicle information, which contains equipped sensors/devices

Figure 4 An example map that shows location blocks.

capabilities, types, and their locations. The resource manager then extracts the sensors/devices information from the vehicle information and stores them separately.

 Duplication check and grouping

In this step, the resource manager checks whether there are duplicated traffic data in a certain area. The occurrence of duplicated traffic data implies that there are more than one sensor/device can provide the same type of traffic data within a location block. The resource manager will group them together and choose several of them in each group to allocate resources based on their CQI.

 Traffic data value computation

Traffic data value computation is a major step in the information importance analysis stage, which computes the traffic data value of each sensor/device. The value is used to determine whether the traffic data provided by these sensors/devices are important or not. We compute based on vehicle type, sensor/device ability, and location. Each of them corresponds to an importance degree which is derived from the QoS requirements.

The equation below computes the traffic data value based on three

The normalization procedure is used to equalize the influence of each importance channel environment is suitable for transmission.

 Required channel resources computation

The resource allocation unit of radio resource in LTE is called a resource block.

The resource manager computes the number of required resource blocks for each sensor/device based on its CQI and sensor/device data producing rate. The cost of traffic data transmission must be measured to evaluate the cost effectiveness of certain CQI, , which also represents the data consuming rate. Based on , we can learn the modulation scheme and code rate to obtain the available data rate according to the LTE specification, which is shown in Table 4 [24]. Note that the larger indicates that we need more resource blocks to support the transmission, therefore, can be used to present the transmission cost.

 Sorting for resource allocation priority

Table 4 CQI MCS mapping table in LTE [24].

CQI index Modulation Code rate x 1024 efficiency

0 Out of range

 Resource limitation check

This step is used to check whether there are enough radio resource blocks for a certain sensor/device. The checking order is according to the previous sorted result.

Let be the total number of resource blocks and is the remaining number of resource blocks. The number of can be derived from the channel bandwidths [25]. We will sequentially check for each if is enough to allocate or not as follows:

 Allocation permitted

After the above procedure, resource manager permits to reserve resources to the vehicular sensors/devices, and decide the QoS parameter settings including QCI, GBR and MBR based on QoS requirements.

5.4.5 Resource reservation

Finally, the resource manager sends the resource allocation results back to the LTE P-GW. Once the dedicated bearer establishment procedure starts, P-GW will inform UEs (vehicles) how resources are allocated based on the previous results.

Chapter 6

Performance Evaluation

6.1 Experimental setup

We implement a system level simulation for our resource management algorithm for multimedia traffic report systems (QoS-MTRS). The environment we built is under the open source network simulator, NS3 [10]. The simulation parameters show in Table 5 below. We simulated 50 eNodeBs, 100 UEs (vehicles) and 200 sensors distributed in a map with 24/54/100 location blocks. The map and the movement trace file of UEs are generated via VanetMobiSim [11].

Table 5 Simulation parameter settings [12][13].

Parameter Value

Mobility model IDM_LC (by VanetMobiSim) RandomWayPoint

Simulated areas 0.3 x 0.2 / 0.4 x 0.5 / 1 x 1 km2

Topology Urban/suburban

Simulation time 5 / 10 / 30 s

Table 6, Table 7 and Table 8 are the importance degrees we adopted in the simulations. Since we regard importance degrees as given values, the numerical values of them are generated randomly.

Table 7 Importance degrees of vehicles.

Vehicle Type 𝒅𝒊𝒗

Police/ Ambulance/ Fire truck 3

Public transportation 2

Household vehicle 1

Table 6 Importance degrees of sensors/devices.

Data Type Data Format Sensor /

6.2 Evaluation results of QoS-MTRS

For performance evaluation, we compare the proposed QoS-MTRS with BQA (bandwidth and QoS-aware scheduler) [5] and two static methods: FCFS (first-come, first-served) and Greedy (greedy, based on traffic data value) scheduler. The performances we concerned are the appearance probability of received traffic data types, overall system throughput, end-to-end delay, duplication ratio (Dup), coverage (Cov) and overall value of received traffic data (S). The above performance metrics have been defined in Chapter 4.

For performance evaluation, we compare the proposed QoS-MTRS with BQA (bandwidth and QoS-aware scheduler) [5] and two static methods: FCFS (first-come, first-served) and Greedy (greedy, based on traffic data value) scheduler. The performances we concerned are the appearance probability of received traffic data types, overall system throughput, end-to-end delay, duplication ratio (Dup), coverage (Cov) and overall value of received traffic data (S). The above performance metrics have been defined in Chapter 4.

相關文件