In mobile agent model, we converts objective requirements into logical roles and then disseminates the logical roles among the network in a distributed manner.
Each logical role will individually operate a updating process according to its type of logical roles. We define a sub-header for data communications between logical roles. Fig. 3.4 shows the structure of the sub-header. The SrcID and DestID are the pair of node ID and role ID (NodeID, RoleID) of a sender role and a receiver role. T otalHops is the hop-count between the sender and receiver. CurHops is the current hop-count from the sender. In a data transmission between two logical roles, a node which is on the routing path of the transmission and its 1-hop neighbor nodes will hear the data packet. According to the sub-header, these nodes can update its routes to the sender and receiver.
12
SrcID DestID TotalHops CurHops Type
Figure 3.4: Sub-header for data communications under mobile agent model.
AggrID Inputs
num In1ID
Type cost1 … InnID costn
(a) AGGR QUERY
NodeID Inputs
num In1ID
Type … InmID cost
num
(b) Type1 AGGR REPLY
AggrID cost Type AggrID cost Type
(c) Type2 AGGR REPLY
Outputs McstID Outputs
num Out1ID
Type cost1 … OutnID costn
(d) MCST QUERY
NodeID
Type Outputs … cost
num Out1ID OutnID
(e) MCST REPLY
Figure 3.5: Control messages
13
3.4.1 Aggregation Role update
Aggregation roles trigger a updating procedure periodically after it is acti-vated. For the race condition issue in the distributed system, an aggregation role requires to lock its input logical roles and the output logical role before it starts the updating process. First of all, the aggregation role A broadcasts an AGGR QUERY message to its K-hop neighbors. The K-hop neighbors examine whether it can be a candidate node for the updating or not. A node C check which inputs of A it can connect. C find a maximum set Ic ⊆ I to satisfy Eq. (3.1) where I is the inputs of A and D(i, j) is the hop-count number between i and j. If C can find a IC, C will become a type1 candidate node and send back a AGGR REPLY message. According to the AGGR REPLY messages, A determines which inputs should be aggregated on which type1 candidate nodes.
Xn j=1
D(icj, C) + D(C, A) <
Xn j=1
D(icj, A), Ic= {ic1, ic2, ..., icn} (3.1)
However, there might be an existing aggregation role which does the same ag-gregation operation and is near A. Hence, the existing agag-gregation role, Aexisting, become a type2 candidate if it satisfies Eq. (3.2).
D(Aexisting, A) <X
i∈I
D(i, A) (3.2)
Type1 candidates are the better nodes to perform the current aggregation role.
Hence, the current aggregation role can be moved or split to the candidate nodes to reduce the transmission cost. Nevertheless, a type2 candidate is an existing aggregation role which already performs the same aggregation operation in the network. That means it is worth to merge the two existing aggregation roles to a single aggregation role.
14
Both type1 and type2 candidates will transmit an AGGR REPLY message to the current updating aggregation role. Then the aggregation role determines which type is better to process updating. For type1 updating, the aggregation role informs its input roles, output role and the candidate nodes to establish the routing relationship and then move or split itself to the candidate nodes. For type2 updating, the aggregation role informs its output role and the candidate role first.
Then the current aggregation role gets destroyed and the candidate role takes a job to serve the output of current aggregation role. Since the candidate role has to serve two output logical roles after merging, a multicast role will be created to serve the two output logical roles. Fig. 3.6 shows an example of type2 updating.
(S1+S3)
Figure 3.6: Type2 updating of the aggregation role .
source role
S3 S3 source role
Figure 3.7: A source role creates a new multicast role on the current node.
15
Algorithm 1 Procedure AggregationRoleUpdate() executed by an aggregation role periodically
1: Lock other corresponding roles
2: Broadcast AGGR QUERY message to its K-hop neighbor nodes
3: Find the best updating candidates by AGGR REPLY messages
4: if T ype2 updating then
5: merge this aggregation role to the candidate aggregation role and then terminate this role
6: else if T ype1 updating then
7: if require split then
8: split the current aggregation role into multiple sub-aggregation roles
9: move those roles to the candidate nodes
10: else
11: move current role to the candidate node
12: end if
13: else
14: (no candidates) sleep for a while
15: end if
3.4.2 Source Role update
A source role can serve more than one logical role. However, setting up mul-ticast roles to relay the raw sensing data takes a chance to reduce the transmission costs. Therefore, a source role will periodically create a new multicast role to cope with its output logical roles if there are more than one logical role associated with it.
3.4.3 Multicast Role update
A multicast role processes an update procedure periodically. The updating procedure of a multicast role is similar to an aggregation role. Conversely, a multicast role, M, updates itself in the reverse direction of an aggregation role.
First, M broadcasts MCST QUERY message to its K-hop neighbors. A node which is received the message will verify routing costs to the outputs of M. A node, C, becomes a candidate node if it find a set Ocwhich satisfies the Eq. (3.3),
16
where O is the outputs of M.
After the candidate nodes return a MCST REPLY message, M chooses the best candidate nodes to perform the current multicast role. Finally, M move or split inself to those candidate nodes. The new position of the multicast role makes a profit in the network since the transmission number of data packets is decreased.
Algorithm 2 Procedure MulticastRoleUpdate() executed by a multicast role periodically
1: Lock other corresponding roles
2: Broadcast MCST QUERY message to its K-hop neighbor nodes
3: Find the best updating candidates by MCST REPLY messages
4: if receive MCST REPLY message then
5: if require split then
6: split the current multicast role into multiple multicast roles
7: move those roles to the candidate nodes
8: else
9: move current role to the candidate node
10: end if
11: else
12: (no candidates) sleep for a while
13: end if