Views:Customizable Abstractions for Context-Aware
Applications in MANETs
Kurt Schelfthout Distrinet-K.U.Leuven
Celestijnenlaan200A 3001Leuven,Belgium kurts@cs.kuleuven.be
Tom Holvoet
Distrinet-K.U.Leuven
Celestijnenlaan200A
3001Leuven,Belgium
tom@cs.kuleuven.be
Y olande Berbers
Distrinet-K.U.Leuven
Celestijnenlaan200A
3001Leuven,Belgium
yolande@cs.kuleuven.be
ABSTRACT
Programming applications for highly dynamic environments such as mobile ad hoc networks(MANETs)is complex,since the work-ing context of applications changes continuously.This paper presents “views”as abstractions for representing and maintaining context information,tailored to applications in MANETs.An application agent can de?ne a view by declaratively describing the context in-formation it is interested in.A supporting middleware platform, called ObjectPlaces,ensures that the information represented by a view continuously re?ects the agent’s context information,de-spite the dynamic situation in a MANET.We elaborate on the dis-tributed protocol that ObjectPlaces uses to maintain the information of views,and give a thorough evaluation.
1.INTRODUCTION
Given the increasing pervasiveness of networks due to the ad-vent of wireless communication,the next generation of distributed systems presumes little network infrastructure,and is comprised of computing devices(nodes)that can be carried around,or are placed on moving vehicles.Mobile computing nodes connected in such an ad hoc way form a mobile ad hoc network(MANET).
An application developed for MANETs necessarily consists of distributed agents that need to communicate among each other to achieve a common goal.Given the dynamics of a MANET,this communication between application agents is complex:the nodes on which these agents live are mobile,and can disappear from a conversation at any time.Dealing with this complexity at the ap-plication level is hard,so an application developer bene?ts greatly from a coordination middleware that offers high level mechanisms to manage communication among agents.
ObjectPlaces is a coordination middleware that supports a?rst order abstraction of an agent’s context.For our purposes,an agent’s context is the aggregate of all available information on currently reachable nodes in the MANET.An agent’s context thus changes because(1)information on a reachable node is changed,or(2) the set of reachable nodes changes.In ObjectPlaces,an agent can gather context by de?ning a view.A view is built by the middleware Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for pro?t or commercial advantage and that copies bear this notice and the full citation on the?rst page.To copy otherwise,to republish,to post on servers or to redistribute to lists,requires prior speci?c permission and/or a fee.
SELMAS’05at ICSE’05May15-16,2005,St.Louis,Missouri,USA. Copyright2005ACM1-59593-116-3/00/0004...$5.00.based on a declarative speci?cation that describes“how far”over the network the view reaches,and in what information the viewing agent is interested in.
The most important property of a view is that it is an actively maintained structure,that changes as the agent’s context changes. The agent can listen for new context events,e.g.the arrival of a new node carrying interesting information.A motivating example for such an active notion of context occurred in a real world ap-plication,wherein we are currently applying the ObjectPlaces mid-dleware.In this application,automatic guided vehicles(AGVs)in a warehouse coordinate to transport goods.AGVs communicate to avoid collisions(among other things);an AGV thus needs to be noti?ed actively when another vehicle enters in a possible col-lision range.Other examples are rescue workers that want to be noti?ed of incoming and leaving ambulances,battle?eld scenarios where soldiers want to be noti?ed of incoming transports,etc.If the middleware does not support an active context representation,the application programmer is forced to program such a representation using polling.
In the following section,we describe the ObjectPlaces middle-ware in more detail,as well its relation to existing coordination middleware.In Sect.3we describe a protocol to maintain a view in a MANET.Then,the ObjectPlaces middleware and speci?cally the notion of a view is evaluated analytically and empirically in Sect.4.Finally,we conclude.
2.VIEWS ON OBJECTPLACES
In ObjectPlaces,each agent can maintain”viewable data”in a local collection of objects called an objectplace1.The objects in an objectplace represent information that is of interest to other agents, and so contribute to the overall context information available.Other agents can gather copies of objects from objectplaces on nodes in their neighborhood using a view.In other words,context informa-tion is made available by putting it in a local objectplace,and can be gathered by building a view.Agents can coordinate by in?uencing each other’s context,much like what happens in everyday traf?c: when a car driver is going to take a right turn,he or she turns on the turning indicator.Other drivers can see this”context change”,and react appropriately.
First we describe how an agent can manipulate its local object-place,then views are described in more detail.The section is con-cluded with a discussion of ObjectPlaces in relation to existing work.
1”ObjectPlaces”-the middleware-is written in plural and with two capitals,”objectplace”-the software entity-is written without capitals.
2.1Manipulating an objectplace
An objectplace by itself is basically a tuplespace variant:an ob-jectplace is a set of objects that can be manipulated by operations such as put,read and take.Contrary to existing tuplespace ap-proaches however,an objectplace has a fundamentally asynchronous interface:operations return control to the client immediately(an agent that uses the middleware is called a client of the middleware), and results are returned as they are available via a callback.This is important in order to allow views to be built ef?ciently and conve-niently,see Sect.2.3.
For clarity,we have made two simpli?cations.First,although an objectplace can be manipulated remotely,for this paper the reader can assume that an objectplace is only locally accessible.Views, discussed in the next section,provide a way for clients to observe the contents of remote objectplaces.Second,although a client can create objectplaces at will,we assume that the middleware offers exactly one objectplace on each node.
Similar to tuplespaces,in order to read or take objects from an objectplace,clients indicate what objects they want to read by means of a template.A template is a function from the set of objects to a boolean value.Every object for which the template function returns true matches with the template.
The operations on an objectplace are the following:
put(Set,Callback)puts the given set of objects in the objectplace.
Returns true to the callback if all objects were successfully
added.
take(ObjectTmplt,Callback)removes the objects matching with the template from the objectplace and returns them to the
callback.
watch(ObjectTmplt,EventTmplt,Lease,Callback)observes the content of the objectplace.Returns copies of objects match-
ing the object template to the callback(the objectplace is not
changed).The event template is used to indicate in what
events on the matching object the client is interested in.Event
template and lease are described in detail shortly.
A watch operation’s event template can match with three pos-sible events:isPresent,isPut or isTaken.If the event tem-plate matches with isPresent,the objectplace returns copies of all matching objects it currently contains to the callback,and re-turns the empty set if there are no matches(this is important for so-called test-for-absence operations,where the client needs to know there are no matching objects).If isPresent is the only event with which the event template matches,the watch operation is?n-ished.However,when the event template also matches with isPut or isTaken,the objectplace must return copies of matching ob-jects that are either put in or taken from the objectplace.In order to do so,the operation is registered by the objectplace,and when an appropriate event occurs on an object matched by the object tem-plate,the client is noti?ed.An event template that matches with isPresent and isPut for example,?rst returns copies of ob-jects currently contained in the objectplace.When new matching objects are put in the objectplace,copies of these are returned in a subsequent call to the callback.Objects returned to the callback are also annotated with the event that occurred on the object,so the client can distinguish between events.
To unregister watch operations that are waiting for an event,a watch can be provided with a Lease object.A client calls the discard operation on the Lease to unregister the corresponding watch operation.The same lease can be given as an argument to more than one watch;in that case,upon discard all these opera-tions are unregistered atomically.2.2Views
A view is a local collection of objects,re?ecting the contents of multiple objectplaces on reachable nodes in the network based on a declarative speci?cation.This collection is continuously updated by the middleware,both with respect to changing contents of the objectplaces in the view,as with respect to changes in the network topology.A view thus represents the context of the viewing agent. To build a view,a client speci?es:
A distance metric and a bound determines“how far”over the net-
work the client’s view will reach.An example is a hop count-
metric with a bound of three:the view will span objectplaces
reachable in a maximum of three hops from the node where
the view is issued.
An object template constrains what objects will be included in the view.
Given these parameters,the ObjectPlaces middleware searches the network for nodes satisfying the constraints(using the protocol described in Sect.3).On these nodes’objectplaces,a watch op-eration with the given object template is executed.The watch’s event template matches with all possible events.The results of all these watch operations,which are events indicating the presence, arrival or removal of objects in an objectplace,are sent to the node issuing the view.This allows the viewing node to keep the view up to date with respect to changes in the content of the participating objectplaces.Changes in the network are handled by managing the watch registrations on the nodes in the view.When it is detected that a node moves out of the view,the view’s watch on the object-place of that node is unregistered,and the viewing node is noti?ed; when a node moves into the view,a watch on its objectplace is reg-istered and consequently the viewing node is noti?ed as well.How this detection is done is discussed in Sect. 3.A view is actively maintained in this way until it is released by the client.Any client on any node can build a view,and clients can specify as many views as they want.Each client can have its own set of views to observe the context that it is interested in.
A client can not only specify constraints on the content of the view based on its interests,the content can also be represented in a client speci?c way(e.g.as a sorted collection).In its raw form, a view is built out of the events generated by the watch operations on the participating nodes,as well as events generated by the mid-dleware when a node leaves or joins the https://www.doczj.com/doc/766799242.html,ers of the middle-ware can program their own representation using these raw events. For example,we have provided an implementation of a view as a collection,supporting a collection interface common in object-oriented API’s(i.e.java.util.Collection in Java).This allows sorting and iterating over the collection for example.The collection is updated as watch events are generated,e.g.when an isPut is received,the corresponding objects are added to the https://www.doczj.com/doc/766799242.html,ually,a view is described as such a collection in this paper,since it is the most common usage pattern.Other represen-tations of a view can be an accumulation to a single value,e.g. the average of an attribute of the objects in the view,or translating objects in the view to objects the agent understands,to deal with heterogeneous agents.Both the contents and the representation of a view can thus be customized.
As an example,suppose a car arriving at an intersection wants to know the positions of other cars,since the car has to give way from the right.It builds a view on all cars within50meters(distance metric and bound),containing position and car id objects(object template).The car chooses a sorted list as representation,closest car?rst.A traf?c monitor nearby also builds a view on nearby
cars,and car id objects,but accumulates the car id’s in a counter for traf?c information purposes.In both cases,the content of the view is partly the same(car id’s),but the representation is different (a sorted list,vs.a count of the unique id’s).
In conclusion,a view is a powerful abstraction that can be put to good use for coordination,since it is an active representation of a agent’s context.A view takes the heterogeneous nature of a MANET into account,because both the contents and the represen-tation of a view can be tailored to each client’s wishes.
2.3Discussion and Related Work
The ObjectPlaces middleware can be seen as a hybrid between two well known approaches for coordination:publish/subscribe systems and tuplespaces.
In a publish/subscribe(P/S)system(e.g.[3,14]),publishers send noti?cations of state changes to a list of subscribers.Sub-scribers are not known in advance but let the P/S middleware know of their interest in certain events through the use of subscriptions. The P/S middleware handles the delivery of noti?cations to the right subscribers.
ObjectPlaces can be seen as a P/S variant:a view is a subscrip-tion to events on objectplaces in the vicinity of a client.Clients ”publish events”by manipulating objects in their local objectplace, which triggers watch operations of views that are observing that ob-jectplace.The resulting events are then delivered to viewing clients. ObjectPlaces solves a problem when applying P/S middleware in MANETS:in[4]it is described that,due to the appearance and reappearance of nodes in a MANET,there is a phase immediately after reconnection in which a mobile subscriber needs to wait until events are published so that the subscriber can assess the current state of publishers.For example in STEAM[9],a P/S middleware for MANETs,publishers are burdened with sending events period-ically to account for possible newly arrived subscribers.Generally, this problem is handled by buffering previous events on reliable and?xed infrastructure,e.g.[5][15].Such a?xed infrastructure is however not available in MANETs.In ObjectPlaces this problem is handled naturally.Objects are put in a local objectplace;newly arrived clients can be brought up to date immediately by querying neighboring objectplaces using a view.At the same time,the view subscribes to events on the objectplace,and so keeps the viewing client up to date in the future as well.The objectplaces thus act as a buffer in which clients can store observable state. Tuplespaces(TS)systems,with Linda[2]as a?rst incarnation, provide a shared collection of data,called tuples,and a set of op-erations(read,write,take)on the collection to manipulate the data. Throughout the years,Linda has spawned many variants,e.g.[1] [16].
Directly applying tuplespace systems in MANETs is dif?cult since clients need to know the location of a tuplespace to interact in beforehand,or a shared tuplespace must be discovered and agreed upon at runtime.Since there is no reliable infrastructure available in a MANET,solving this problem is not trivial.In ObjectPlaces, the solution is to let agents manipulate a local objectplace,com-bined with the use of a view to gather the contents of objectplaces on reachable nodes.From this viewpoint,a view is the necessary ”discovery mechanism”that detects reachable objectplaces accord-ing to client-speci?c constraints.
As another point,objectplace operations are speci?cally designed to support views ef?ciently.Existing tuplespace approaches lack the event-based,asynchronous interface an objectplace provides. An event-based interface is necessary since a view requires active maintenance,so the viewing agent needs to be noti?ed whenever an objectplace in its view changes.Since a tuplespace provides mostly synchronous operations(e.g.rd,rdp),a tuplespace would have to be polled regularly to keep the view up to date,which is an inef?cient solution.With a watch operation,the client can query both the current contents(isPresent)and subscribe to events on the objectplace(isPut and isTaken).This ensures that the ob-jectplace noti?es the client when appropriate,thus eliminating the need for polling.
Although existing models do support event-like operations(e.g. JavaSpaces’notify[16]or LIME’s reactions[10]),these are not suf?cient.For example,JavaSpaces notify can”only”send noti?-cations of incoming tuples,while a view also needs to react to ob-jects that are removed from an objectplace in order to be up to date. Another issue is that an objectplace supports both querying the cur-rent contents and subscribing to events atomically:otherwise,a view may miss some objects.JavaSpaces can support this by pro-viding a transaction mechanism,but we feel this is too heavyweight for application in a MANET.Also in programmable or extensible tuplespaces like TuCSoN[11]and MARS[1],extending the in-terface with asynchronous operation is possible,but these mecha-nisms are too heavyweight for application in MANETs.The ob-jectplace’s watch operation solves the problem by allowing clients to specify an appropriate event template.
Finally,we discuss the relation of ObjectPlaces to a number of coordination middleware approaches speci?cally for MANETs. LIME[10]is a middleware for mobile agents and mobile nodes that attaches a personal tuplespace to each agent in the applica-tion,and shares these tuplespaces transparently when two agents are on the same or connected node.The LIME middleware was extended recently in EgoSpaces[12].In EgoSpaces,clients can build a view over the locally available network,similarly based on a distance metric.EgoSpaces’view is always represented as a tu-plespace(supporting primitives like in,inp,...).In ObjectPlaces, the representation of the view can be tailored to the client’s wishes (e.g.a sorted collection),thus supporting heterogeneous agents bet-ter.Furthermore,while it is possible to register reactions on a view in EgoSpaces,these can react”only”to incoming tuples[7].It is unclear how an agent can be noti?ed of a tuple leaving it’s view (except by polling),a necessary precondition for building an up to date client-side representation such as in ObjectPlaces.
TOTA[8](Tuples On The Air)is a middleware that provides ap-plications with the notion of a self-maintaining distributed tuple. Each node in the network hosts a tuplespace.A distributed tuple is propagated to nearby nodes,and can be changed with each propa-gation according to an application-speci?c rule(e.g.counting the number of hops from the root).This tuple is then maintained by the middleware as the network changes.An important difference with ObjectPlaces is that a view is speci?c for every client,while a dis-tributed tuple is the same for all observers.In other words,while in TOTA the”sender”of a message(the agent that adds a distributed tuple)determines both who it reaches and what the content is,in ObjectPlaces the”receivers”of a message(the clients that build a view)can determine both content and representation.
3.VIEW PROTOCOL
The construction of a view in a MANET requires a distributed protocol that is able to?nd and maintain a set of reachable nodes in the network given a bound on a distance metric.This means that the protocol should be able to:(1)notify the viewing node when a node enters or leaves the view(2)register and deregister watch operations on nodes entering and leaving the view respec-tively;(3)route the events generated by the watch operations to the node where the view was de?ned.Existing ad hoc routing pro-tocols(for an overview,we refer to[13])are not adequate because
they can only provide a?xed”distance metric”(usually hop count). Since the distance metric used for building the view is application speci?c and determined at runtime,we need a protocol that does?t our requirements.This protocol can be viewed as an alternative to the one proposed in[12].
We assume from the underlying network layer that:(1)a single-hop broadcast is available that broadcasts a message to all nodes within communication reach,represented by the function broadcast (message);(2)a reliable single-hop unicast that sends a message
to a designated node within communication reach,represented by the function unicast(message,id receiver).We can reasonably expect these functions to be built based on data link standards such as IEEE802.11[6].
Algorithm1The view protocol.
on timeout t br
1:removeOutdated(participants,f p.t br)
2:broadcast(dist msg(id view,0,id root))
on receive content message c
3:updateT ime(participants,timestamp(c),c.id sender)
4:updateV iew(participants,c.events)
5:
Process Participant:
on timeout t br
6:removeOutdated(neighbors,f n.t br)
7:id parent=findP arent(neighbors)
8:d current=calculateDistance(neighbors,id parent)
9:if d current≤bound then
10:broadcast(dist msg(id view,d current,id participant))
11:events=objplace.watch(object template,allEvents,cb) 12:unicast(cont msg(id view,events,id participant),id parent) 13:else
14:alive=false
15:stop timer
on receive distance message d
16:updateT ime(neighbors,timestamp(d),d.id sender)
17:updateDistance(neighbors,d.distance,d.id sender)
18:alive=true
19:start timer
on receive content message c
20:if alive then
21:unicast(c,id parent)
The data structures necessary for the protocol are depicted in Ta-ble1,while the protocol is depicted as Algorithm1.The protocol builds and maintains a shortest path spanning tree,starting on the node with the client issuing the view,called the root.This tree de-termines which nodes are included in the view-these are called the participants in the view.In the text and in algorithm1the protocol
is described as if there is only one view-this is only for exposi-tory purposes.In reality this protocol is executed for every view
in which a node participates.That is why with each message a unique view id,id view is transmitted.The data structures in table
1are also for one single view,and are duplicated for every view in which a node participates.
The length of a path is determined by the distance metric,which
is a parameter of the protocol.This allows building a shortest path based on hop count,but also on any other distance metric such as physical distance,or bandwidth.The only constraint on the dis-tance metric is that it increases monotonically the further it gets propagated from the root,to ensure that the distance does not grow out of bounds as it gets propagated in a loop.Such a metric can always be chosen,by including a hop count with any other metric the client chooses(e.g.physical distance)[12].
The view building process starts when a client issues a view.The node on which this client is located is responsible for building and maintaining it,and is the root for that view.The root?rst builds a unique id for the view,consisting of its own id and a sequence number that is unique on each node.Two activities now occur in parallel:the building and maintaining of the shortest path spanning tree,and the building and maintaining of the contents of the view. The contents of the view is maintained at the root and consists of a list of participants and the objects their objectplaces currently con-tain.
The spanning tree.To build and maintain the spanning tree, the root and all participants regularly broadcast distance messages. This allows participants to determine what their distance is from the root(d current),given the view’s distance metric.The root starts the tree-building process by broadcasting a distance message with the id of the new view,its own id and a distance of zero(line2). Nodes that receive a distance message check whether they are par-ticipants in the view.To this end,each participant maintains a list of its neighbors-nodes from which it has recently received a dis-tance message.Upon receipt of a distance message,the participant records the time the distance message was received from that neigh-bor(function updateT ime,l.16),and the distance that neighbor broadcasted(function updateDistance,l.17).The participant sets the alive variable to indicate it should check whether it is in a view, and starts a timer(if the participant already was in the view,these have no effect).
After every broadcast period,given by t br,a participant recalcu-lates its distance from the root based on its list of neighbors.First, neighbors for which the timestamp of the distance message that was last received is older than a given timeout,are removed(us-ing removeOutdated,l.6).This timeout is given as a neighbor freshness factor f n that is multiplied with t br to determine the ac-tual timeout.The participant then determines the neighbor that is closest to the root using findP arent(l.7).Based on its parent’s distance,it calculates its own distance from the root d current us-ing the distance metric(l.8).If it is within the bound,it broadcasts a distance message itself(l.10),and repeats the process every t br time to account for changes in the tree.Otherwise,it goes to sleep, waiting for new distance messages to come in that might change the situation(l.14-15).The end result of this protocol is that each node regularly checks whether or not is in the view,and knows a parent in the tree which is the closest to the root of all its neighbors. The contents of the view.Each node that is in the view,deter-mines the objects it contributes to the view by executing a watch operation on its local objectplace.The resulting events of this watch are transported to the root using content messages.The events variable is the set of buffered events at the participant that have not been sent to the root yet(we are stretching notation in line 11,since these events are actually sent to callback cb).A node that receives such a content message from one of its children forwards it to its parent,so that it reaches the root(l.21).The root main-tains a list of participants of the view.For each content message it receives,it updates the objects that participant contributes to the view(using updateV iew,l.4).It also records the reception times-tamp of each content message(l.3),and removes those participants it hasn’t heard from for f p.t br time,where f p is the freshness of the participants(l.1).This means that participants must periodi-cally send a content message to the root,even when there are no events to be returned(events={})to ensure that the root does not consider them out of the view(l.12).
This protocol tolerates mobility of any node and disappearance
Root Participant Distance msg Content msg id view id view id view id view participants=neighbors=id sender id sender {(id participant,timestamp,{object})}{(id neighbor,timestamp,distance)}distance{event} distance metric,bound id parent,d current
object template distance metric,bound
object template
Table1:Contents of data structures and communication messages.
of participants.New nodes are discovered by the periodic broad-casting of the distance messages.Nodes that should be removed from view are detected because they discover for themselves that they don’t have any more neighbors,or their distance has gone out of bounds.Changes in the spanning tree are similarly detected through exchange of distance messages.
Using the spanning tree to deliver events.When sending con-tent messages,the spanning tree is actually used as a multi-hop routing tree to the root.Although the shortest path from partici-pant to root may not always be known,at least some path exists (possibly temporarily containing cycles)and events are delivered as long as every node on the path forwards the content message to its parent.
However,in the case where a node that received an event goes down before forwarding the event,the event is lost.To compensate for this loss,one can choose to use a reliable link protocol from node to root,such as the alternating1-bit protocol.Each event re-ceived by the root would then have to be acknowledged before the node can send another event.Although this makes the protocol re-liable,it also induces additional overhead.One possible solution is to use unreliable best-effort event delivery,which may be tolerable for some applications where the view may be slightly incorrect or out of date.Regularly,the view may be“?ushed”and current state from all nodes is sent again.
Propagation of other parameters.The parameters of the view, such as the distance metric,also need to be sent from the root to the participants.This was not discussed,but is done in a straight-forward way:whenever a node receives a distance message with an id view it does not know,it requests the relevant view parame-ters from the sender of the distance message.When the node deter-mines it is not in the view,it may delete this information-or decide to keep it for a while longer because it might become a participant in the view later.We do not elaborate further.
4.EV ALUATION
The following parameters in?uence the correctness and the per-formance of the view:(1)the broadcast period t br,(2)the freshness for neighbors f n,and(3)the freshness for participants f p.Instead of letting the application designer choose these experimentally,we mathematically derive bounds on these parameters,supporting the designer in making the right trade-offs.
The view protocol is in?uenced by uncontrollable factors con-cerning the dynamics of MANETs.In order to keep the presenta-tion clear,we focus on the dynamics of the network only-in other words we assume for the rest of this section that the contents of the objectplaces stays the same.We focus on this problem because this is where any problems and bad assumptions will be revealed. Speci?cally,we take into account the number of nodes on a given area and the speed of these nodes.The speed in?uences how busy the protocol will be updating changes,and the concentration deter-mines connectivity,or the number of nodes in the view.
We study how accurately the protocol can represent the perfect view,which is obtained by“stopping time”and comparing the view the protocol built at that time with how the view should look,given the current position and connectivity of the nodes.There are two kinds of errors:false exclusions,objects that are not in the view but should be;and false inclusions,objects that should not be in the view but are.
4.1False exclusions
A?rst way how false exclusions occur is when a node enters the view,while the view didn’t notice the new arrival yet.The critical parameter to minimize this kind of false exclusion is the broadcast period.When this period is short enough,a new node entering the view receives a distance message from a neighbor early,and the view updates fast.Suppose nodes have communication range r, and relative speed v r,and we want to detect a node when it has traveled at most distance l into communication range of any par-ticipant.The worst case scenario occurs when an undetected node moves straight at another in the view.In this case,the maximum broadcast period to ensure that a node is detected is:t br≤r?l
v r
, with no transmission delay and no message loss.
Supposing a message can get lost with probability p loss,then the minimum broadcast period to ensure that a node is detected at a distance l with minimum probability p detect is:t br≤r?l
n.v r
,with n the number of resends until a probability of receiving a message p detect is reached.From the inequality p detect≥1?p n loss,it follows that n≥log(1?p detect)
loss
.
To incorporate message delays,these bounds should be tighter: one should subtract the message delay from a node to its neighbor and subtract the delay to send the contents from the new participant to the root.
The second way a false exclusion occurs is when the root re-moves a participant while it should not,because a content message did not reach it in time.We write the time it takes to send a message i as t d,i(from the start of sending to the end of receiving),the time of reception of message i as t rec,i and the freshness of a participant as f p.For each two consecutive content messages1and2it should be true at the root that t rec,2≤t rec,1+f p.t br,otherwise a par-ticipant is removed in error.After some calculation,this becomes: t d,2?t d,1≤(f p?1).t br.This inequality gives a lower bound for both the freshness and the broadcast period.The inequality shows that the bound is dependent on the difference between two delays only.This means that if the delay increases fairly slowly,the proto-col adapts to this increase.Only when the delay suddenly increases with a value of(f p?1).t br does a false exclusion result.In other words,the broadcast period and the freshness determine the robust-ness of the protocol to message delays and congestion.
The upper and lower bound described above show the tradeoff between accuracy and performance.The smaller the broadcast pe-riod,the more accurate and responsive the view becomes.How-ever,sending more messages affects the performance,and causes congestion.Choosing a small broadcast period and freshness also causes errors in the view by decreasing the protocol’s tolerance for
l.w size of area100.100m2
t sim duration of the simulation30minutes
r transmission range of the nodes20m
N number of nodes variable
v node speed variable
d rang
e o
f the view in hops variable
t send,t rec duration of send and receive50ms
Table2:Simulation parameters.
delays.The bounds given accurately characterize the trade-off to make and so support the designer in his or her decisions.
4.2False inclusion
False inclusion occurs when a node moves out of range or out of distance of the view,while the view still contains the node’s contents.Two parameters in?uence this:the broadcast period t br and the freshness of the participants f p.Two scenarios exist.
In the?rst scenario,a node that is in the view moves out of range. The time it takes to detect this is maximum f p.t br+t d,where t d is the total transmission delay to successfully send a content message from the node to the root.
In the second scenario,the node is within communication range but for some reason the network changes and the node is out of the view(i.e.it’s distance becomes greater than the bound on the view distance).The node is still within communication range with other nodes in the view.The total time it takes to remove this node from the view is t br+t d+f p.t br,so a broadcast period longer than the ?rst scenario since it is only after this time that the node’s parent broadcasts a new distance,so the node realizes that its distance from the root has changed.
Concluding,in order to minimize errors,the broadcast period and the freshness should be as low as possible.However,as was shown in the previous section,this makes the protocol more brittle.
A similar trade-off must thus be made.
4.3Simulations
The goal of the simulations is to evaluate whether a MANET is able to sustain a view-like concept.Instead of focussing on achiev-ing a detailed simulation that conforms to reality as much as pos-sible,we instead opted for a more straightforward approach that exposes the reasons behind problems more easily,while still re-?ecting the most important realities in a MANET.
In the simulations,N nodes move around randomly on a rect-angular area of size l.w,with a constant speed v.Each node has a prede?ned transmission range r.A node within that range can receive messages from the node.Sending and receiving messages takes time,resp.t send and t rec.Nodes move a distance every second.All other activities occur instantly.Of the nodes moving around,one root node tries to build a view with a distance metric that increases one unit with each hop,and a bound denoted by d(in other words,we want the content of all objectplaces within d hops). All nodes have an objectplace which contains exactly one object. This never changes-we focus again on the dynamism of the net-work,not of the objectplaces’content.All results are obtained by doing10runs for t sim minutes each with identical parameters,and then averaging the results.The parameters are summarized in table 2.
First,the in?uence of the speed and concentration of the nodes on the number of errors in the view is studied,?xing d=3.In ?gure1(a)we see the total number of seconds a view is wrong ver-sus the number of nodes on the given area,for different speeds,due to false exclusions and false inclusions.The speed does not in?u-ence the error signi?cantly,but the concentration does.This is as expected,because the broadcast period was set to500ms,which gives the view plenty of time to update given the range of speeds we are looking at.However,we see that the number of views that are wrong due to false exclusions is very high with higher concen-tration of nodes.The reason for this is congestion:too many nodes in the view mean that content messages are not reaching the root in time,which causes the root to remove participants in error.This is due to the fact that f p=1,which is the most unforgiving value possible(see Sect.4.1).
To?nd a good trade-off,we?xed v=0.5m
s
,d=3and N=25,a scenario that gave quite some errors in the previous tests.We also set f p=2.f n,because as the content messages are multi-hop,they are more susceptible to delay.As can be seen in ?gure1(c),the combination of freshness and broadcast period in-?uences the correctness of the view greatly.Good values for this particular scenario seem to be t br=2000ms and f n=1,or al-ternatively t br=1000ms and f n=2.5.As was shown in the analysis,a shorter broadcast period and smaller freshness do not increase the accuracy of the view:on the contrary,they cause con-gestion which does more harm than good.The improvement ob-tained by choosing a higher broadcast period alone is remarkable, and stresses the importance of this parameter.
So far,we have looked at the total number of seconds a view is wrong,and have been able to reduce this time from100%to about 16%of the total duration.Although these numbers don’t look very promising,the criteria for marking a view as wrong are harsh:if only one object is missing,or should be missing but is included, the whole view is“wrong”.However,such a view may still be accurate enough to be used for practical purposes.
In order to know how wrong the view actually is,we measured the total duration a node is falsely in-or excluded,and the average size of the view measured in the number of nodes included per sec-ond,for the same runs as the previous experiment.We found that the number of nodes in the view was on average8nodes(averaged over time).The number of falsely excluded nodes per second is 3.50.The protocol manages to build the perfect view84%of the time,and gathers contents from70%of the content it should gather the rest of the time.Similar results are obtained for false inclusions, where the problem was less severe to begin with.
The results are workable for applications where network infras-tructure is not available(e.g.search and rescue scenarios)or where a best effort approach is tolerable(e.g.calling a cab via a PDA). However,the described protocol is but one way of supporting a view;in the automatic guided vehicle application discussed in the introduction,we are actually using a wireless network with access points in order to improve the reliability of communication.Col-lision avoidance is an application in which a best effort approach is not adequate.However,the concepts ObjectPlaces offers remain the same and retain their strengths for mobile applications;only the underlying implementation differs.
We do not discuss message overhead,an area in which improve-ments are possible(especially in the presence of multiple views). We leave this for future work.
5.CONCLUSION
This paper discussed a middleware system for MANETs that provides a powerful abstraction of context to the application.In ObjectPlaces,agents coordinate by building a view on informa-tion made available by remote agents in the network.The view is actively maintained,and is client-speci?c both in contents and in representation.We presented a distributed protocol that maintains such a view in a MANET,and showed acceptable performance re-
(a)
(b)(c)
Figure1:(a)False exclusions vs speed,(b)False inclusions vs speed,(c)False exclusion for different broadcast periods and freshness, with f p=2.f n.
sults,mainly focussing on the accuracy of the view.While for the construction of a view we necessarily take a best-effort approach, it was shown that good insight in the working of the protocol helps performance.
An interesting direction for future work is to provide to the appli-cation using the view an indication of how good the view represents reality at this point in time-in other words,estimate the accuracy of the view and show this to the application.This estimate can for example be based on a node’s location and a known probability distribution of the nodes in space,or can be learned through expe-rience.This is useful where the accuracy of the view is important. If nodes know the view is probably wrong,they can move more slowly or change the broadcast frequency in order to increase the accuracy.
6.REFERENCES
[1]G.Cabri,L.Leonardi,and F.Zambonelli.Mars:A
programmable coordination architecture for mobile agents.
IEEE Internet Computing,4(4):26–35,2000.
[2]N.Carriero,D.Gelernter,and J.Leichter.Distributed data
structures in linda.In Proc.13th ACM Symposium on
Principles of Programming Languages,1986.
[3]A.Carzaniga,D.S.Rosenblum,and A.L.Wolf.Design and
evaluation of a wide-area event noti?cation service.ACM
Trans.on Computer Systems,19(3):332–383,2001.
[4]M.Cilia,L.Fiege,C.Haul,A.Zeidler,and A.P.Buchmann.
Looking into the past:enhancing mobile publish/subscribe
middleware.In Proc.of the2nd intl.Workshop on
Distributed Event-based Systems,2003.
[5]L.Fiege,F.C.Grtner,O.Kasten,and A.Zeidler.Supporting
mobility in content-based publish/subscribe middleware.In
Proceedings of the ACM/IFIP/USENIX International
Middleware Conference,2003.
[6]IEEE Computer Society LAN MAN Standards Committee.
Wireless lan medium access control(MAC)and physical
layer(PHY)speci?cations.IEEE Std802.11-1997,1997. [7]C.Julien and G.Roman.Active coordination in ad hoc
networks.In Proceedings of the6th International Conference on Coordination Models and Languages,2004.
[8]M.Mamei and F.Zambonelli.Self-maintained distributed
tuples for?eld-based coordination in dynamic networks.In
The19th Symposium on Applied Computing(SAC04),2004.
[9]R.Meier and V.Cahill.Exploiting proximity in event-based
middleware for collaborative mobile applications.In
Proceedings of the4th IFIP International Conference on
Distributed Applications and Interoperable Systems
(DAIS’03),2003.
[10]A.Murphy,G.P.Picco,and G.-C.Roman.Lime:a
middleware for physical and logical mobility.In Proc.of the 21th International Conference on Distributed Computing
Systems(ICDCS-21),May2001.
[11]A.Omicini and F.Zambonelli.The TuCSoN coordination
model for mobile information agents.In Proc.of the1st
Workshop on Innovative Internet Information Systems,1998.
[12]G.-C.Roman,C.Julien,and https://www.doczj.com/doc/766799242.html,work abstractions
for context-aware mobile computing.In Proceedings of24th International Conference on Software Engineering,pages
363–373,2002.
[13]E.Royer and C.-K.Toh.A review of current routing
protocols for ad-hoc mobile wireless networks.IEEE
Personal Communications,1999.
[14]B.Segall and D.Arnold.Elvin has left the building:A
publish/subscribe noti?cation service with quenching.In
AUUG97,1997.
[15]Sun Microsystems,Inc.Java message service1.1,2002.
[16]Sun Microsystems,Inc.The javaspaces v1.2.1spec.,2002.
表情符号大全 ?new news?new news? ???????????● ?●?????????????????♂♀????????⊙◎?????????????????????◇?????の★☆→あぃ￡Ю〓§???¤????????≈???.. ..????? ???????? ~.~??-????【】┱┲?????????????????????????????????★☆??⊙????????╬『』∴? .??????????☆∷﹌の★◎??????
??????↘??▄█▌????????????????の☆→ ?ぃ￡?????????????????????????????????????????????????????????????????????????????????????*????????????????????????o(?\'\'\'?)o?べò????????????べ?????????：基本符号?.1 ⊙●○①⊕◎Θ⊙¤㊣★☆♀◆◇◣◢◥▲▼△▽⊿◤◥?.2▆▇█ █ ■ ▓ 回□ 〓≡ ╝╚╔
╗╬ ═ ╓ ╩ ┠┨┯┷┏?.3┓┗┛┳⊥『』┌ ┐└ ┘∟「」↑↓→←↘↙♀♂┇┅﹉﹊﹍﹎╭?.4╮╰╯*^_^* ^*^ ^-^ ^_^ ^（^ ∵∴‖｜｜︴﹏﹋﹌（）〔〕?.5【】〖〗＠：！/ " _ < > `,·。≈{}~ ～() _ -『』√ $ @ * & # ※?.6卐々∞Ψ ∪∩∈∏ の℡ぁ§∮”〃ミ灬ξ№∑⌒ξζω＊?.7．·°∴☆．．·°?Yesterday ?．·°?.8?KicaZ宝贝o(╥﹏╥)o ??じ☆ve 【??????】*°^_^.......???.9 ┢┦aΡpy ?^_^??????ぜ长ヤ乷?????Cool Friends??????.10【】—一▄【┻┳═一▄【┳一▄【┻═┳一▄【┳-一?.11 ▄【┻═
全形顏文字 得意<(￣︶￣)> 乾杯[]~(￣▽￣)~*滿足(￣ˇ￣) 沒睡醒(￣﹏￣) 狡猾(‵﹏′) 被打一巴掌(￣ε(#￣)無言(￣.￣) 無奈╮(￣▽￣)╭ 裝傻(￣▽￣)~* 驚訝(⊙?⊙) 發現(￣.￣)+ 驚嚇Σ( ° ?°|||)︴冷(￣▽￣)" 沒辦法╮(╯▽╰)╭貓咪臉(=￣ω￣=) 疑惑(￣３￣)a 阿達(￣0 ￣)y 重創(。_。) 不(＞﹏＜) 懷疑(→_→) 睏(￣o￣) . z Z 崇拜m( __ )m 我想想(ˇ?ˇ)
生氣<(￣﹌￣)> 就是你<(￣﹌￣)@m Orz 挫折系列顏文字 這是經典... 大頭Orz 小頭orz 翹XXXXX Or2 放大版○|￣|_ 雙手撐地ORZ 有表情囧rz 變化形OTL 換邊STO 換邊(小) _no 動物顏文字豬頭( ˉ(∞)ˉ ) 蝸牛"\@ 章魚(:?)≡ 蟑螂((( ●< 毛毛蟲(??)nnn 蝌蚪(: )～ 顏文字組合 使用時可加( ) 例：˙﹏˙ →(˙﹏˙） ˙?˙˙０˙˙︿˙˙ε˙˙ 3˙˙ω˙˙﹏˙˙?˙˙▽˙小眼睛
⊙?⊙⊙０⊙⊙︿⊙￣ε￣￣3￣⊙ω⊙⊙﹏⊙⊙?⊙⊙▽⊙大眼睛 ￣?￣￣０￣￣︿￣￣ε￣￣3￣￣ω￣￣﹏￣￣?￣￣▽￣瞇瞇眼 ∩?∩∩０∩∩︿∩∩ε∩∩3∩∩ω∩∩﹏∩∩?∩∩▽∩微笑眼 ∪?∪∪０∪∪︿∪∪ε∪∪3∪∪ω∪∪﹏∪∪?∪∪▽∪悲傷眼 ˋ?ˊˋ０ˊˋ︿ˊˋεˊˋ3ˊˋωˊˋ﹏ˊˋ?ˊˋ▽ˊ生氣眼 ＞?＜＞０＜＞︿＜＞ε＜＞3＜＞ω＜＞﹏＜＞?＜＞▽＜緊閉眼ˇ?ˇˇ０ˇˇ︿ˇˇεˇˇ 3ˇˇωˇˇ﹏ˇˇ?ˇˇ▽ˇ不爽眼 ╯?╰╯０╰╯︿╰╯ε╰╯3╰╯ω╰╯﹏╰╯?╰╯▽╰無奈眼 ≧?≦≧０≦≧︿≦≧ε≦≧3≦≧ω≦≧﹏≦≧?≦≧▽≦嬉皮眼 ????０??︿??ε??3??ω??﹏??△??▽?鬥雞眼 ????０??︿??ε??3??ω??﹏??△??▽?金魚眼 ●?●●０●●︿●●ε●● 3●●ω●●﹏●●?●●▽●外星人 ＋?＋＋０＋＋︿＋＋ε＋＋3＋＋ω＋＋﹏＋＋?＋＋▽＋小丑眼 日系顏文字精選 (????)(??`ω′?)(?(?)?)(σ｀?д?)σ(o?ω?o) 小眼睛 (???)(???*)（p?_q）(〃?ｏ?〃)(*^?_?) (。???。) (*?０?)(?ε?●)(??ω?)(。?д?。)(???)（／??、）(?□?、*)(?－?。) (?▽?。)(?_?。) (?O?。)(ノ??。)(＠???)(*??*)人(?ε?；) (?o ?)(?ェ?o)(′???『) 瞇瞇眼 (* ￣ー￣)(￣ー￣〃)(＠￣ー￣＠)(* ￣︿￣)(*￣?￣*)<(??*)> (￣(●●)￣)(￣??￣)(ー?ー)(￣ｏ￣)(￣、￣)(*￣?￣*)(￣へ￣)(￣□￣) (￣～￣；)(。-?-。)(￣ε￣；)(￣┬￣；)(￣?￣)(ノへ￣、)(*￣ro￣)(ー人ー)(*￣ｍ￣) 日系小眼睛 (′▽`〃)(′ｏ`)(′ェ`)(′ε` )(=′ー`) ( ′θ`)(′○` )( ′－`)(′?`=)(*′▽`) (*′ノ0`)( ′ロ` )(′～`；）(′︿`)(*′?`*) (′ｍ`）(′0ノ`*)(＠。ε。＠) (=′?`=）(●′ω`●) (′～`●)(′へ`、)(〃′o`)(；′⌒`) 日系大眼睛 (ΘΘ)(Θ～Θ〃)(ΘｏΘ)(ΘェΘ)(Θ?Θ＃)(ΘдΘ；)(Θ皿Θメ)(ΘーΘ*)(Θ０Θ●)(Θ▽Θ)(ΘεΘ?)(Θ?Θ。)(ΘへΘ)(Θ?Θ=)(Θ、Θ)(Θ?Θ＠)(Θ３Θ) 圓珠眼 (°ー°〃)(＃°Д°) (。□。) (*。?。) (*。?^*)(* ^ー。) (＠。ー。＠)(。?^?)(ｏ。?。) (。▽。) (＃。ε。＃) (。?^d)(。?。；)(。皿。メ)(* 。３^) (〃。ｏ。〃) ( °?°)(。?。) (°□°；) (ロ)。。(。Д。；)(*。ノO。)(；。。) 緊閉眼 (><)(;><)(>_<)(>.<)(>o<)（＞▽＜）(＞Ｏ＜)(o>▽<)(>?< ) (>▽<)(;>?<)( >з<)(o>ェ<)(＞д＜)(>皿<)(>_<、)(/_＜。)(>。；)(>。ヘ)(ノ_<)(＞。?)(>y<;)
囧???⊕?Θ?¤㈱㊣??????▕??▓?▔⊿??▂▃▄▅▆▇██■?回□』∵╝╚╔╗╬═╓╩┠┨┯┷┏┓┗┛┳?》「┌┐└┘∟〉《′?″?↘↙??┇┅﹉﹊﹍﹎╭╮╰╯*^_^* ^*^ ^-^ ^_^ ^（^ ∮?‖｜｜︴﹏﹋﹌（）【】」『〒〓＠：！/\ " _ < > `,?。?{}~ ～() _ -》「?$ @ * & # ?卐??Χ∪∩‵?の℡〔§?＂?ミ灬μ??～μδω＊ ㄚ??＋－??＋－a／＝∫???∧∨??‖※??∶∷?＜＞じ?veve′?????■?》「Χ?″??㊣?～〒〓＠μδω□?』??ぷ?卐」『??∩¤????∽ㄚ∵↘↙┗┛╰?╮∽??????????≈???≌?????≒????????丨丩丬丶丷丿乀乙乂乄乆乛亅亠亻冂冫冖凵刂讠辶釒钅阝飠牜饣卩卪厸厶厽孓宀川巜彳廴三彐彳忄扌攵氵灬爫犭病癶礻糹纟罒冈耂艹虍言西 兦亼亽亖亗盲凸凹卝卍卐匸皕旡玊尐开木囘囙囚四囜囝回囟因女团団囤亢囦囧囨云囱囫囬园化囯困囱囲図围抡囶囷正囹固囻囼国图囿圀圁圂圃吾圅圆囵圈幸青国圌围园圏圐圑员圆圔圕图圗团圙圚圛圈圝圞 一般常用特殊符号 ，、。．？！～＄％＠＆＃＊? ；?…¨，??? ‘’“”＂?｀?〃′??″↖↗↙↘㊣???⊕?????????□■▔▓§?〒????? 贴图符号大全 A、希腊字母大写ΑΒΓΓΔΕΖΘΗΚ∧ΜΝΞΟ?Ρ?ΤΥΦΦΧΨ B、希腊字母小写αβγδεδεζηθικλμνπξζηυθχψω C、俄文字母大写АБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ D、俄文字母小写абвгде?жзийклмнопрстуфхцчшщъыьэюя E、注音符号??ㄅㄌㄐㄔㄘ?ー??ㄆㄉㄙㄍㄑㄕ?ヽ??ㄇㄊㄚㄎㄒㄖ???ㄈㄋㄛㄏㄓㄗ F、拼音o?ǎ-、ōμǒ′、±?°?ˉ、?3ǐ2、ū?ǔ·、ǖǘǚǜ1 G、日文平假名〔ぃぅぇぉかきくけこんさしすせそたちつってとゐなにぬねのはひふへほゑまみむめもゃゅょゎを H、日文片假名?ィゥヴェォカヵキクケヶコサシスセソタチツッテトヰンナニヌネノハヒフヘホヱマミムメモャュョヮヲ
≡(▔﹏▔)≡⊙﹏⊙∥∣°ˋ︿ˊ﹀-# ╯︿╰﹀ (=‵′=) <(‵^′)> (-__-)b ￣□￣｜｜-----\\(˙<>˙)/----- <("""O"""> (O ^ ~ ^ O) (*^︹^*︺( /。\ ) ( ' – ' ) ( ^３^ )╱~~ (；°○° ) ( > c < ) <(￣︶￣)> <(￣︶￣)/ b(￣▽￣)d 汗(￣口￣)!! ╮(￣▽￣)╭╰(￣▽￣)╭╮(￣﹏￣)╭ (￣▽￣@) ○(￣﹏￣)○ <(￣oo,￣)/ ╮(￣▽￣"╭︿(￣︶￣)︿ 凶手!凶手就是你! <(￣﹌￣)@m 我..我..是大猪头╭(﹊∩∩﹊#)╮来嘛!╮(╯◇╰)╭口禾火～口禾火～…(⊙_⊙;)…○圭~○列~怎么酱？ <(￣oo,￣)/猪头不是一天造成的! ˋ(′o‵")ˊ这个你问我也不知道~ 有火星人~ \("▔□▔)/\("▔□▔)/ 不要以为我不知道咩!┌(‵▽′)╭<(￣ c￣)y▂ξ真烦,来哈根草吧~ 叔叔~这样很冷耶! （＃－.－）/ 我是优质大帅哥一枚. \(￣▽￣)♂♀(￣▽￣)/ 我是优质大美女一枚. ┐(─__─)┌你说我有啥米办法咧~ 吃饱饱，睡好好! ○(*￣︶￣*)○有没有被猪揍过啊? ○(#‵︿′#)○ε(┬┬＿┬┬)3 我真命苦 .. 拆屋┴┴︵╰(‵□′)╯︵┴┴≡￣﹏￣≡冷到不行.. <(‵^′)> 我看你还是回火星去好了! <(￣oo,￣)/ 没看过猪哥吗??... <(￣︶￣)/ 喜欢吗？把拔买给你～︿(￣︶￣)︿这学期欧趴欧趴啦～无影脚升级版 <( ￣^￣)︵θ︵θ︵θ︵θ︵θ︵θ︵θ︵θ︵θ☆( >_<)~啊! 恶魔集团o(‵▽′)ψ(￣︶￣)ψ(￣︶￣)ψψ(╰_╯)σ☆咒 嘟着嘴 (￣)︿(￣) \(～__～)/ 要抱抱啦... 满意.满足 <(￣︶￣)> []~(￣▽￣)~* (￣﹏￣) (￣ˇ￣) \(￣︶￣)> <(￣︶￣)/ (‵﹏′) ╮(‵▽′)╭\(‵▽′)/ =============================================
Ansoft 协同设计方法 －复杂波导系统设计 2008-06-12 ANSOFT CORPORATION
目录 前言 (2) 一、 Ansoft复杂无源器件仿真解决方案 (2) 二、波导滤波器的设计 (4) (一) Iris 波导滤波器设计 (4) 1) 在HFSS中进行的基本单元建模和仿真 (4) 2) 建立HFSS与Ansoft Designer间的动态链接 (10) 3) 在Ansoft Designer中求解 (14) 4) 在Ansoft Designer中完成滤波器的优化设计 (15) 5) 将Ansoft Designer中优化后的IRIS滤波器export到HFSS进行验证 (17) (二) Combline滤波器设计 (19) 1) 在HFSS中进行基本单元的建模仿真 (19) 在求解设置部分可参考前述IRIS波导滤波器的设置，所不同的是求解频率为0.4GHz (34) 2) 在HFSS中进行基本单元的参数化扫描 (41) 3) 建立HFSS与Ansoft Designer间的动态链接 (42) 4) 在Ansoft Designer中完成滤波器的优化设计 (46) 5) Ansoft Designer 与 HFSS的仿真结果对比与讨论 (48)
前言 HFSS精确可靠的三维电磁场仿真彻底改变了传统设计流程， 调试硬件原型的传统设计手段被对三维电磁场仿真模型的设计和优化所取代，大大地缩短了设计周期。尽管如此，Ansoft仍不懈地致力于优化使用者的仿真设计流程，提高优化效率，从而进一步缩短设计周期。 现今对于滤波器或其他复杂波导器件的理论研究和设计技术已经非常成熟，但设计工作依旧面临很多问题。电路仿真具有很高的速度，可快速的仿真出滤波器各个部件的集总电参数，但是在电磁场求解工具中设计真实的3D微波元件却需要花费数周的时间。本文主要阐述了电路仿真器如何与3D场仿真器协同完成设计工作，从而使设计周期从原先的数周缩短为数日。这种解决方案的核心是“场路结合、协同仿真”，优点是有效的结合了三维电磁场仿真的精度和电路仿真的速度，使微波无源器件的设计流程进入了新的时代。 下面我们将以几个具体的例子来说明这套通过“场路结合、协同仿真”来设计复杂无源器件的解决方案。 一、 Ansoft复杂无源器件仿真解决方案 当电磁场仿真被设计者广泛接受后，我们进一步需要把这种技术应用到各种需要精确仿真求解的更大规模的设计问题中。这里就产生了一对速度与精度之间的矛盾，因为我们知道电路仿真速度是很快的，传统的仿真方法一般都是基于等效电路的。我们希望有一种切实可行的解决方案：能提供快速、具有电磁精度、且求解问题的规模不受限制。因为作为工程设计软件，仅仅解决求解精度问题是不够的，更重要的是能够提供一种高效率的、可操作性强的设计流程。“场路结合、协同仿真”的思路就是基于这种实际工程中的需求而产生的。 Ansoft提供的这套复杂无源器件仿真的解决方案如下图所示：
《网络表情符号》 1.认识作者，积累重要字词。 2.理清文章结构思路，把握文章主旨。（教学重点） 3.结合本文内容，学习方法及其作用，并加以熟练使用。（教学难点） 【教学过程】 一、新课导入 “海内存知己，天涯若比邻。”当唐朝诗人王勃在为离别而伤感惆怅时，绝对想不到他的美好愿望如今早已成真。计算机网络的出现，改变了整个世界，也随时随地影响着我们的日常生活的点点滴滴。特别是QQ、微信等各种交流软件更是深受大众喜爱，而在这其中，那些非常有趣的网络表情便功不可没，尤其受到年轻一辈追捧。那么，今天就让我们走进课文《网络表情符号》，一起来了解这种让我们非常受用的网络表情的来源和发展过程吧！ 二、自主预习 1.走进作者 邱雨，编辑、记者。 申江婴，男，毕业于南京邮电学院，现任新华网党组成员、董事、副总裁，曾任工信部主管的中国网友报总编辑、中国信息产业网总裁等职务。长期从事通信信息化、互联网领域的新闻报道和新媒体、移动互联网的市场运营主要管理者工作。被聘为工信部信息通信经济专家委员会委员、文化部公共文化专家、国家新闻出版总署客座教授、北京邮电大学软件学院客座教授、南京邮电大学经济管理学院客座教授、中国信息经济学会产学联盟推进中心主任委员、中国互联网协会应用创新工作委员会常务副主任委员，享受国务院政府特殊津贴。 2.字音字形 （1）重点字 风靡（mǐ）囧（jiǒng）衍生（yǎn）瞠目结舌（chēng）独树一帜（zhì）．．．．．（2）形近字 风靡（mǐ）荒诞（dàn）独树一帜（zhì）．．． 糜烂（mí）垂涎（xián）编织（zhī）．．． 3.词语解释 风靡：草木随风而倒。形容事物很风行。 荒诞：极不近情理。 口水战：用言语进行相互的攻击或激烈的争论。 瞠目结舌：瞪着眼睛说不出话来，形容惊呆的样子。 l拍案叫绝：拍桌叫好;形容非常赞赏。 独树一帜：单独打起一面旗号.比喻风格新奇;自成一家.也比喻自立门户。 4.网络表情符号 三、合作探究 （一）整体感知 1.通读全文，理清文章结构 明确：本文主要由四个部分组成： 第一部分(1自然段)写斯科特?法尔曼教授在电脑中输入人类历史上第一张微笑符号。 第二部分(2-5自然段)写网络表情符号被广泛认可，并开始在网络上流行。 第三部分(6-12自然段)写网络表情符号在日本和中国得到快速发展，衍生了许多带有东方特
Ansoft高级培训班教材 ISM天线射频特性的Ansoft HFSS分析 李磊谢拥军编著 西安电子科技大学Ansoft培训中心
目录 第一章序言 第二章 创建项目 第三章 构造模型 第四章 优化
第一章序言 本讲义主要是引导学员学习使用Ansoft HFSS的优化功能进行微波工程设计。随着越来越多的民用科研产品集中在ISM频段，这一频段的微波元器件设计也就越来越受到射频工程师的关注。对于民用产品来说，微带天线适应了其集约化、小型化的需求，从而成为产品设计中的关键。 Ansoft HFSS提供的优化设计功能，特别适合于微波产品的优化设计。在这一优化功能中，结构参数、媒质本构常数等可以作为待优化的参数，元件的S参数、本征值和场分布等都可以作为优化的目标函数。学员通过可以本讲义的练习，熟悉这一功能。 这本手册的后边部分描述将引导你如何使用软件去建立、仿真和优化一个ISM天线的axial ratio（轴比）。本例假设使用者已经学习过并理解指南中的“The Getting Started”的内容。 备注：如果你对该内容不熟悉，请翻看指南中“Using the 3D Solid Modeler”部分。 该天线是一个右手圆极化天线（RHCP），工作在2.4GHz的ISM频率 (Bluetooth, 802.11b, etc. )
第二章创建项目 本章中你的目标是： √保存一个新项目。 √把一个新的HFSS设计加到已建的项目 √为项目选择一种求解方式 √设置设计使用的长度单位 时间：完成这章的内容总共大约要5分钟。 一.打开HFSS并保存一个新项目 1.双击桌面上的HFSS9图标，这样就可以启动HFSS。启动后的程序工作环境如图： 图2－1 HFSS工作界面 1．打开File选项(alt+F),单击Save as。2．找到合适的目录，键入项目名hfopt_ismantenna。 图2－2 保存HFSS项目
各种表情符号的英文说法全在这里了 各种表情符号的英文说法拿微信来说，里面的表情符号都有自己的描述，简直是不看不知道，一看就懵圈了！第一排：Smile微笑Grimace撇嘴Drool色Scowl发呆CoolGuy得意Sob流泪Shy害羞第二排：Silent闭嘴Sleep 睡Cry大哭Awkward尴尬Angry发怒Tongue调皮Grin 呲牙第三排：Surprise惊讶Frown难过Ruthless酷Blush 冷汗Scream抓狂Puke吐对此本君只想说：其实，这些还都算正常啦，再看看Buzzfeed网站上的这几道题~本君觉得有必要为Emoji设立四六级了。看表情，猜含义，小伙伴们开始吧（老规矩，直接点击选项看答案~）Expressionless Face 面无表情Neutral Face 不动声色Straight Face 一本正经Face With Flat Mouth 扁嘴Playful Face 顽皮Crazy Face 疯狂Face With Stuck-Out Tongue and Winking Eye 吐舌眨眼Face With Wink 眨眼Nervous Face 紧张Anxious Face 焦虑Disappointed But Relieved Face 失望但如释重负Guilty And Caught Face 愧疚并被抓现行Concerned Face 关切Astonished Face 诧异Surprised Face 惊讶Hushed Face 缄默Rude Face 粗鲁Unamused Face 不爽Dissatisfied Face 不满意Eye-Roll Face 斜眼Apologetic Face 抱歉Pensive Face 忧郁Guilty Face 内疚
四.设置边界条件和激励源26 五.设置求解条件31 第二章创建项目 本章中你的目标是： √保存一个新项目。 √把一个新的HFSS设计加到已建的项目 √为项目选择一种求解方式 √设置设计使用的长度单位 时间：完成这章的内容总共大约要5分钟。 一.打开HFSS并保存一个新项目 1.双击桌面上的HFSS9图标，这样就可以启动HFSS。启动后的程序工作环境如图： 图2－1 HFSS工作界面 1．打开File选项(alt+F),单击Save as。2．找到合适的目录，键入项目名hfopt_ismantenna。
图2－2 保存HFSS项目 二.加入一个新的HFSS设计 1．在Project菜单，点击insert HFSS Design选项。( 或直接点击图标。)一个新的工程被加入到hfopt_ismantenna项目中，默认名为HFSSModel n。 图2－3 加入新的HFSS设计 2．为设计重命名。在项目树中选中HFSSModel1,单击鼠标右键，再点击Rename项，将设计重命名为hfopt_ismantenna。
图2－4 更改设计名 三.选择一种求解方式 1．在HFSS菜单上，点击Solution Type选项. 2．选择源激励方式，在Solution Type 对话框中选中Driven Mode项。 图2－5 选择求解类型图2－6 选择源激励方式 四.设置设计使用的长度单位 1.在3D Modeler菜单上，点击Units选项. 2.选择长度单位，在Set Model Units 对话框中选中mm项。
图2－5 选择长度单位图2－6 选择mm作为长度单位 第三章构造模型 本章中你的目标是： √建立物理模型。 √设置变量。 √设置模型材料参数 √设置边界条件和激励源 √设置求解条件 时间：完成这章的内容总共大约要35分钟。 一.建立物理模型 1．画长方体。 在Draw菜单中，点击Box选项（或直接点击图标）；
◆◇表情符号大全◇◆粉多的~~~~不进来后悔啊`~~~ 来源：https://www.doczj.com/doc/766799242.html,/f?kz=114574371 表情符号 T_T 流眼泪的样子 ~~>_<~~ 痛哭，十分伤心 ⊙ ⊙睁着眼睛看着你 ^_~ 俏皮地向对方眨眼睛 *o* 陶醉 :p 吐舌头 @_@ 高度近视 <@_@> 醉了 o_o 盯着... ^o^ 扮鬼脸，或者很得意，很自豪 O_O 吃惊 -_- 神秘的笑容 ^_^ 快乐的人儿 ＿.,＿裂开嘴轻声笑 ^v^ 很憨地笑 ^^v 成功了，高兴地笑，在用胜利的手势 (^-^) 欢喜 (^o^) 欢喜 *^____^* 大笑 =_=^ 得意 =^_^= 脸红的人儿 *^_^* 脸红 =_= 晕 +_+ 昏迷 ?_? 茫然，不明所以 $_$ 贪心 ~_~ 生气 T^T 生气 >o< 愤怒 .\ /. 愤怒 e_e 困，想睡觉 －_－# 分特（分特＝faint、晕，即很无奈、很受不了）－_－b 流汗 －_－^ 流汗 >_< 表示要发飚了，准备收拾人；或者极度郁闷 －O－打呵欠 愉快的情况 └(^o^)┘;偶头好状壮ㄋㄟ``` ﹌○﹋喔嗨呦^ˇ^≡
\^o^/ 欢呼 ^o^y 胜利^o^y ↖(^ω^)↗小猪为你打气! ~^o^~ 加油呦! *^?^* 笑,打 *^ο^*哦～,呵呵傻笑 *^◎^* 呵呵大笑(嘴唇好厚) *^÷^* 得意的笑(有上下唇的哟) ~~~^_^~~~ 笑毙罗(笑得连眼泪都蹦出来了...) (-.-)=3 松ㄌ一口气~ ~~~///(^v^)\\\~~~ 微笑表示友善!!!~哈~哈~ ~@^_^@~ 可爱呦! \\*^o^*// 可爱ㄋㄟ~ ~*.*~ 害羞又迷人的小女生 #^_^# 脸红了!! ∩__∩y耶~~^^ (装可爱?!) (*^@^*) 乖～(还含个奶嘴哦) X﹏X糟糕.. 完蛋的意思呀~~ (°ο°)~@晕倒了.. {{{(>_<)}}} 发抖 ╯﹏╰粉无奈~~ \(╯-╰)/ 很没劲/无耐的意思 (╯^╰〉一脸苦瓜 }_} 粉无奈..粉悲情 -____-" 唉~~别提了..... ._. 受到打击,表情呈现呆滞样～ (*@^@*〉悲,晕 -(- 好伤心. //(ㄒoㄒ)// 流泪中... ::>_<:: 哭 〒_〒鸣~~我在哭... %>_<% 我要哭了哦... ╰_╯我发火了!! 生气的意思~~~眉毛都翘起来~~ >_<# 粉生气~冒青筋 @x@ 生气 (ˋ^ˊ〉-# 生气 (>﹏<) 不～ (*+﹏+*)~ @ 受不了～ x__x, 唉..... 别哭了! 讶异的 >_<|||很尴尬~!!! ^_^; 尴尬 ⊙﹏⊙‖∣°真尴尬～～ ^_^|||好尴尬! ^_^" 尴尬的笑..... →_→怀疑的眼神~~
表情符表情符號大全號大全 └(^o^)┘; 偶頭好狀壯捏 ﹌○﹋喔嗨呦^ˇ^≡ ~^o^~ 大家安安!! =^_^= 溫馨的微笑!!! Y(^_^)Y 舉雙手勝利 \^o^/ 歡呼 ^o^y 勝利^o^y ↖(^ω^)↗小豬為你打氣！ ~^o^~ 加油呦! *^?^* 笑，打 *^ο^* 哦～，呵呵傻笑 *^◎^* 呵呵大笑（嘴唇好厚） *^÷^* 得意的笑（有上下唇的喲） ~~~^_^~~~ 笑斃囉（笑得連眼淚都蹦出來了...）(-.-)=3 鬆ㄌ一口氣~ ~~~///(^v^)\\\~~~ 微笑表示友善!!!~哈~哈~ ~@^_^@~ 可愛呦! \\*^o^*// 可愛ㄋㄟ~ ~*.*~ 害羞又迷人的小女生 #^_^# 臉紅了!! ∩__∩y 耶~~^^ (裝可愛?!)
（*^＠^*）乖～（還含個奶嘴哦）X﹏X糟糕．．完蛋的意思呀~~ (° ο°)~@ 暈倒了.. {{{(>_<)}}} 發抖 ╯﹏╰粉無奈~~ \(╯-╰)/ 很沒勁/無耐的意思 （╯︿╰﹀一臉苦瓜 ︸_︸粉無奈..粉悲情 -____-" 唉~~別提了..... 。_。受到打擊，表情呈現呆滯樣～ （*@︿@*﹀悲，暈 -︵- 好傷心. //(ㄒoㄒ)// 流淚中... ::>_<:: 哭 〒_〒鳴~~我在哭... %>_<% 我要哭了哦... ╰_╯我發火了!! 生氣的意思~~~眉毛都翹起來~~ >_<# 粉生氣~冒青筋 @x@ 生氣 （ˋ︿ˊ﹀-# 生氣 （＞﹏＜）不～ （*+﹏+*）~ @ 受不了～ x__x, 唉..... 別哭了!
=============================================== ============== ?狀況外時會發生的情況 ?訝異的 >_<||| 很尷尬~!!! ^_^; 尷尬 ⊙﹏⊙∥∣°真尷尬～～ ^_^||| 好尷尬！ ^_^" 尷尬的笑..... →_→ 懷疑的眼神~~ ..@_@|||||.. 頭昏眼花 …(⊙_⊙… ○圭~○列~~怎麼醬？ o_o .... 沉思(說穿了"呆滯狀況" O__O" 呆滯的眼神~~~!! ///^_^....... 造成"冷"...乾笑~ ?o?||| 聽無(就是聽不懂ㄉ意思啦^^) ( )? 什麼意思?? (+_+)? 不知道你在什麼 （?ε?）? 哩公啥哇聽無啦~ o_O??? 發生啥事? @_@a 搔頭，疑惑 一一+ 銳利的眼神~ >"<|||| 傷腦筋的意思~ ‵(*>﹏<*)′ 好刺激..
乾杯[]~(￣▽￣)~* 得意<(￣︶￣)> 滿足(￣ˇ￣) 沒睡醒(￣﹏￣) 狡猾(‵﹏′) 被打一巴掌(￣ε(#￣) 無言(￣.￣) 無奈╮(￣▽￣)╭ 裝傻(￣▽￣)~* 驚訝(⊙?⊙) 發現(￣.￣)+ 驚嚇Σ( ° △ °|||)︴ 冷(￣▽￣)" 沒辦法╮(╯▽╰)╭ 貓咪臉(=￣ω￣=) 疑惑(￣３￣)a 阿達(￣0 ￣)y 重創(。_。) 不(＞﹏＜) 懷疑(→_→) 睏(￣o￣) . z Z 崇拜m( __ )m 我想想(ˇ?ˇ) 生氣<(￣﹌￣)> 就是你<(￣﹌￣)@m 日系顏文字精選 都是一些一看就很容易懂的圖 (????)(??`ω′?)(?(?)?)(σ｀?д?)σ(o?ω?o) 日系顏文字系列 怕解釋的不夠好，乾脆不作解釋 小眼睛 (???)(???*)（p?_q）(〃?ｏ?〃)(*^?_?) (。???。) (*?０?)(?ε?●)(??ω?) (。?д?。)(???)（／??、）(?□?、*)(?－?。)(?▽?。)(?_?。) (?O?。)(ノ△?。)(＠???)(*??*)人(?ε?；) (? o ?)(?ェ?o)(′???『) 瞇瞇眼 (* ￣ー￣)(￣ー￣〃)(＠￣ー￣＠)(* ￣︿￣)(*￣?￣*)<(? ?*)>
(￣(●●)￣)(￣??￣)(ー?ー)(￣ｏ￣)(￣、￣)(*￣△￣*)(￣へ￣)(￣□￣) (￣～￣；)(。-?-。)(￣ε￣；)(￣┬￣；)(￣?￣)(ノへ￣、)(*￣ro￣)(ー人ー) (*￣ｍ￣) 日系小眼睛 (′▽`〃)(′ｏ`)(′ェ`)(′ε` )(=′ー`) ( ′θ`)(′○` )( ′－`)(′?`=)(*′▽`)(*′ノ0`)( ′ロ` )(′～`；）(′︿`)(*′?`*) (′ｍ`）(′0ノ`*)(＠。ε。＠) (=′?`=）(●′ω`●) (′～`●)(′へ`、)(〃′o`)(；′⌒`) 日系大眼睛 (ΘΘ)(Θ～Θ〃)(ΘｏΘ)(ΘェΘ)(Θ?Θ＃)(ΘдΘ；)(Θ皿Θメ)(ΘーΘ*)(Θ０Θ●)(Θ▽Θ)(ΘεΘ◎)(Θ◇Θ。)(ΘへΘ)(Θ?Θ=)(Θ、Θ)(Θ△Θ＠)(Θ３Θ) 圓珠眼 (°ー°〃)(＃°Д°) (。□。) (*。?。) (*。?^*)(* ^ー。) (＠。ー。＠)(。?^☆)(ｏ。◇。) (。▽。) (＃。ε。＃) (。?^d)(。?。；) (。皿。メ)(* 。３^) (〃。ｏ。〃) ( °◇ °)(。⊿。) (°□°；)(ロ)。。(。Д。；)(*。ノO。)(；。。) 緊閉眼 (><)(;><)(>_<)(>.<)(>o<)（＞▽＜）(＞Ｏ＜)(o>▽<)(>◇<) (>▽<) (;>△<)(>з<)(o>ェ<)(＞д＜)(>皿<)(>_<、)(/_＜。)(>。；)(>。ヘ)(ノ_<) (＞。☆)(>y<;) 小狗嘴 (-ω- )(+ω+)(*ω* )( ^ω^)(;ω;)(。ω。)(『ω′)(?ω?=)(￣ω￣) (〃ω〃)(≧ω≦)(。?ω?)(=?ω?=)( ＞ω＜)(′?ω?`)(/ω＼)(/ω?＼) (/?ω?＼)(ΘωΘ)(ΦωΦ) 悲傷眼 (ＵＵ＊)(ｕｕ〃)(ｕｏｕ〃)(Ｕ３Ｕ*)(●Ｕ_Ｕ●)(ｕ～ｕ=) (＠Ｕ▽Ｕ＠)(ＵAＵ＊)(Ｕ△Ｕ●)(ｕДｕ〃)(Ｕ◇Ｕ◎)(○ｕAｕ○) (ｕ▽ｕ＃)(＠Ｕ～Ｕ＠)(ｕ△ｕ＊)(ｕ◇ｕ〃)(ＵДＵ◎)(=ｕ３ｕ=) (ｕ_ｕ＃)(ＵｏＵ＊) ＜（￣︶￣）＞满足且得意 ＜（￣︶￣）／满足并且伸出手表示赞同 ＜（＠￣︶￣＠）＞满足地脸红 （＃￣▽￣＃）害羞 ＼（￣︶￣）／抱抱 ｂ（￣▽￣）ｄ竖起双手拇指说好 ╰（￣▽￣）╭眉飞色舞 （￣︶￣）↗出发吧 ○（＊￣︶￣＊）○吃饱睡好
/:：）微笑［Smｉlｅ］/：：～伤心[Gｒimaｃe] /::B 美女[Ｄｒool］/：:| 发呆[Scowl] /：８-）墨镜［ＣoolＧuy] /:：〈哭［Soｂ] /：:$ 羞[Shy］ /::Ｘ哑［Ｓilｅｎｔ］／：:Z 睡［Sｌeep] /::’(哭[Cry] /::—｜囧［Aｗkｗard] /：:@ 怒[Ａngｒy］/::Ｐ调皮［Tongue] ／：:D 笑[Ｇriｎ] /::Ｏ惊讶[Suｒprise］/:：( 难过[Ｆｒoｗn］／::+ 酷[Ruthless] /:–b 汗[Bluｓｈ] /::Ｑ抓狂［Ｓcｒeam] /::T 吐[Pｕｋe] /：,@Ｐ笑［Chuckｌe] /：，@—D 快乐[Joyful] /::d 奇［Ｓlight] /：,@o 傲[Ｓmug] /::g 饿［Huｎgry］/：|—) 累［Ｄｒowｓy］／:：！吓［Panic] /:：L 汗［Sweaｔ］/：:〉高兴[Lauｇh］/：：,＠闲[Cｏmmａndｏ] /:,@f 努力[Deｔeｒmiｎed]
/::—Ｓ骂［Ｓcold］ /:? 疑问[Shoｃｋeｄ］/：，＠x 秘密［Ｓhhh] /：,@＠乱[Dｉｚzy] /:：８疯［Torｍenｔeｄ] /：,@! 哀[Ｔoasted] /:！！! 鬼[Sｋｕll] /:xx 打击［Ｈaｍmer] /：bｙe bye ［Wave] ／:ｗipｅ汗［Spｅecｈlesｓ] /:diｇ抠[NosePｉｃk］／:hａｎdclaｐ鼓掌[Cｌap］ /:＆—( 糟糕[Shａme] /:Ｂ—) 恶搞[Trick] /:〈@ 什么[Bah！L］ /:@＞什么 [Bah！Ｒ] ／:：—Ｏ累[Yawn] /:>-| 看［Pooh-pooｈ］/:P—（难过[Sｈrｕnｋen] /:：’｜难过[TearingＵｐ] /：X-) 坏[Ｓｌy] ／::＊亲［Ｋiｓｓ］ ／：＠x 吓［Wｒaｔh］/:８* 可怜[Whiｍper］ ／:pｄ刀[Cleavｅr］ /:〈Ｗ> 水果［Wａｔerｍelon] /:beer 酒［Beer］ /：ｂasketb 篮球［Ｂaskeｔball] /:oｏ乒乓[PinｇＰｏng］/：cｏffee 咖啡［Coｆfee] /:ｅat 美食[Ｒice］