## 3 The SOMM Model
### Achieving Flexibility via Virtual Machine
#### 3.3.5 QoS Guarantee  
An important aspect of designing a multimedia system is QoS guarantee. If a server accepts to provide a service to a client with a specified QoS, it must guarantee that the quality of service does not change as long as the service is not finished. Some algorithms are proposed to guarantee QoS in  
Figure 5: A symbolic tuple space. Read and write can be synchronous or asynchronous.  
multimedia systems. RSVP [28] is one of these algorithms. The main idea in RSVP is to stabilize the QoS via reserving required resources. RSVP is a receiver-initiated QoS protocol. In other words, receivers are required to send reservation requests along the path to the sender. A sender in RSVP first sets up a path to potential receivers and provides the flow specification of the data stream to each intermediate node. When a receiver is ready to accept incoming data units, it first places a reservation request along its upstream path to the sender. When a sender receives a reservation request, it checks whether enough resources are available or not. The request is also passed to a policy control module to check whether the receiver has permission to make the reservation. If these two tests succeed, resources can be reserved.  
In a GWMSN, reservation of resources in an intermediate node may be irrational; for the reason that nodes of networks have very limited energy, bandwidth and processing capabilities. Therefore, a node should not be an intermediate node of more than one stream. Consequently, in SOMM a simple protocol is proposed to lock the intermediate nodes of data streams, which is briefly described in the following paragraph.  
When a client sends its request to the base station, the base station refers to the proper service registry and finds the address of server node. Then, it forwards the request of client to that server and also sends a reservation request to all intermediate nodes. All nodes of the network have a table which contains the information about their direct neighbors. This table also shows whether a neighbor is busy or not. When a node \(n\) receives a reservation request from the base station, it informs its neighbors that it is busy. Neighbor nodes then update the status of \(n\) in their table as a busy node and they won't send their data through node \(n\). Node \(n\) also informs the service registry that it is busy. After locking intermediate nodes, server can start sending data to client. When server completes its work, it notifies the intermediate nodes and service registry and they update their tables and mark the server node as a free node. Since wireless communications channel in a GWMSN is unreliable and also node failure is a prevalent event, locking mechanism may lead to a situation in which an intermediate node remains locked forever due to a message lost or server failure. To solve this problem in SOMM, each locked intermediate node of a stream uses a timer to keep the time since receiving last packet. If the timer exceeds a threshold, the locked node discerns that some problem happened to the stream and frees its resources. This threshold is a trade-off: assigning a small value to this threshold may lead to tearing a live stream and therefore losing the QoS guarantee. In another way, giving a large value to this threshold wastes the network resources. Determining the best value for this threshold in a general purpose framework may be a difficult task. But SOMM is a multimedia middleware and multimedia applications are generally real time applications and employ smooth streams. This smoothness in streams is a key for finding a good value for this threshold.