## 3 The SOMM Model
### Achieving Flexibility via Virtual Machine
#### 3.3.1 Virtual Machine and Code Mobility  
A node in a GWMSN should be capable of providing multiple services. Hence, all nodes must have the code for all possible services that the GWMSN can provide. But, because of limitation in resources such as memory and processing capabilities in a GWMSN node, and also the fact that the size of multimedia applications are relatively large, it is not possible to have all the codes for all possible services in each node of GWMSN. Even if it is possible, the result is wasting valuable resources in the network. Also if there is a need to modify a service or add a new service to the network, the new code must be propagated to all nodes, which is a power consuming task and waste lots of energy.  
SOMM proposes code mobility as a solution for the mentioned issues. The codes of different services are stored in a code repository (a rich node that has enough memory) as mobile agents. Server nodes download and run proper code for their services at runtime, considering requested QoS from their client. In this way, there is no need to store all codes in all nodes of network. Moreover, if a service changed or a new service should be added to the network, the new code should simply be sent to the code repository.  
Figure 2 shows the SOMM architecture in a server node. Agent management sub-system is responsible for managing agent mobility. Each agent is an autonomous process which can migrate across nodes. An agent consists of instruction memory, data memory, program counter, operand stack and heap. During migration, the agent manager in source node, packs the agent and its execution context (which contains the necessary information for resuming agent execution in destination node) and then transfers the agent to the destination node using agent transmitter component. Agent  
Figure 2: SOMM Architecture in a server node.  
transmitter component in destination node takes the transmitted agent and brings it to the agent manager. After that, agent manager unpacks the received agent and resume its execution.  
Services in SOMM are provided by agents and there are two types of agents in SOMM:  
* Proxy agent, that is responsible for providing a well defined interface for the corresponding service.
* Service agent, which encompasses the implementation of corresponding service.  
A client connects to the proxy agent and declares its QoS requirements. The proxy agent queries the code repository and downloads and runs the suitable service agent for the corresponding service with the specified QoS requirements. The client does not have any information about the service agent and only communicates with the proxy agent. Communications between proxy and service agents also take place through tuple space. Using this approach, the implementation and interface of services are separated; modifying and replacing implementation of services can be done easily and also it is possible to have different implementations for a service considering different QoS requirements. For example, a server which provides multimedia streams to its clients can download and execute different encoding algorithms based on specified QoS by clients.  
Byte-code interpreter sub-system is the core of SOMM and its main task is to interpret and execute the agents. Networking sub-system sits on top of operating system network stack and is responsible for initial configuration of network and also contains the needed routing protocols which we describe later.