Latest Posts

Sunday, November 4, 2012

Building High-Performing Teams

Well-integrated, high-performing teams - those that 'click' - never lose sight of their goals and are largely self-sustaining. In fact, they seem to take on a life of their own. And it's all down to leadership.

In every case that has been studied at the Europe-based Centre for Organizational Research, teams that 'click' always have a leader who creates the environment and establishes the operating principles and values that are conducive to high performance. The evidence for this is clearly seen in organizations where a manager who creates high performance moves to another part of the organization, or a different organization, and within 18 months they once again establish a high performing team.

We believe these leaders operate in an organized, systematic way to build successful teams, and that the formula not only involves what leaders should say and do, but also what they should not say and do. It also involves working backwards - leaders should envisage the future before dealing with the present.

The four most significant behaviors consistently demonstrated by high-impact leaders are:

» defining clear goals or a vision of the future in accordance with overall organizational aims (the 'big picture')

» creating blueprints for action to achieve those goals

» using language to build trust, encourage forward thinking and create energy within the team ('powerful conversations')

» getting the right people involved ('passionate champions').

Imparting a clear vision of where the team should be headed, and inspiring its members to make it a reality, is fundamental to team success. The great American tennis player Arthur Ashe had a wonderful phrase: "I never worried about winning or losing. I just went for it every time." Leaders who get teams to click consistently have their members tied together and "going for it".

This takes considerable effort on the part of a leader, so it's useful to reflect on why it's worthwhile. As the English manager in a large aerospace company explained to me, "It's a lot of work to get a team to click. It's a lot more work to live with a team that isn't clicking." It's as if successful team leaders calculate the up-front investment and then adopt a process to get the team to pull together to maximize the return on that investment.

Here is what high-impact leaders do. They create a clear vision and describe it in simple language. They take the time to get people to subscribe, or buy in, to that vision. Next, they assess the current situation, then work through the courses of action which are likely to yield results. It is the up-front work in getting to a clear end state that makes the process work.

This foundation-laying aspect of leadership is a determining factor in why some teams seem to grasp and then do their utmost to achieve organizational goals. It's all about how the leader continually visualizes a positive end result. So, when things get tough for the team (as they always do), these extraordinary leaders reintroduce the big picture with phrases like: "Remember our objectives," and "Let's keep our eye on the ball". This consistent single strategy of starting with the future and then moving back to the present allows leaders to make the tough decisions which enable the team to recognize and articulate problems ("What's really up?" or, "What's really so?"), sort through possible solutions, and then take action.

Teams that consistently don't 'get it together' over a long period of time can put up tough opposition for leaders who want to move forward. We like to say that such teams get 'caught in the swamp'. Unfortunately, what they also do is pull others into the swamp with them.

From extensive research, we conclude that extraordinary leaders employ distinctive forms of verbal communication. It is what these leaders say and what they don't say that gives them an advantage in getting teams to high-performance levels. These leaders truly mean what they say. They don't mix their messages, fudge meanings or use ambiguous words. Their conversations are always candid, clear, and followed by committed action.

We call them 'powerful conversations', because they make blueprints come alive and create positive attitudes and energy on the part of team members. They also encourage mutual understanding between team members and the leader; use language to make a vision seem real and worth attaining. A 'powerful conversation' typically progresses in four stages.

Stage 1: Before getting into the specific details of goals and objectives, high-impact leaders spend all the time that's needed on forming a clear vision (e.g., the general shape of a desired outcome or future state) which makes possible complete, undisputed acceptance of its attainability.

Stage 2: This entails a very candid and clear discussion of what people are thinking and feeling. The high-impact leader makes sure that everyone's agenda is heard and explored. He or she carefully asks questions to make sure there is a genuine expression of beliefs, expectations and even fears, while also patiently ensuring that the conversation remains relevant to the big picture. This keeps all those involved out of the swamp, and enables them to set up a useful and realistic agenda. Once this is done, the high-impact leader assesses the agenda.

Stage 3: The high-impact leader now skillfully discusses with team members the issues enmeshed in their proposed agenda. In this way, the leader can deepen his or her understanding of the team's goals and bring to the surface any hidden agendas. The high-impact leader describes scenarios linking future outcomes with the current situation, then proceeds to refine them. He or she continues to keep the process focused on the target future state, and helps the team to see how far it has moved and what progress it has made.

Stage 4: The leader makes sure participants know exactly what steps need to be taken next, and that they are open about what they will do to turn their commitments into reality - making the team 'alive'. The closing of a powerful conversation is also the time when a leader makes sure there is absolute buy-in, or belief in what the team is setting out to do, that team members' commitments are clear and accepted, that all action steps are well-defined and understood. In this way, the high-impact leader ensures that the powerful conversation will produce results.

These are the four most significant behaviors consistently demonstrated by high-impact leaders. But they are not the only such behaviors. What follows is a less detailed but fuller list of what leaders should do to get people to work together to attain organizational goals.

TOP TEN LEADERSHIP TECHNIQUES FOR BUILDING HIGH-PERFORMING TEAMS

Source of Information : PhilHarkins 10 Leadership Techniques for Building High Performing Teams.
read more...

Friday, August 3, 2012

Tracking Domain Rank and Page Rank

Domain rank and page rank capture the value, authority, and trustworthiness of a site or page. These metrics play a key role in determining how you will rank in the search results. Domain rank looks at the entire site and how authoritative it is, while page rank looks at a specific page. Google only provides PageRank data, and this data is usually updated only a few times a year. To get at this data we need to use third-party tools that approximate how Google and Bing perceive the weight and importance of a page. The more authoritative a page is perceived to be, the more weight it has to redistribute its authority.

Think of page rank as a cup that can be filled up. Once it’s filled, it can then fill up several other cups (or in this case, other websites). It does this through linking to other pages. Every link on a page can fill up another page a little bit, but no cup can be empty, so it retains a bit of its rank as well. The result is that the further a page is from an authoritative site in links, the less on that site’s value will trickle down to that page.

When page rank is passed, it is split evenly across all links, including no follow links— so, a page with 10 links, two of which are no follow links, would still pass only one tenth of its authority to each of the other eight pages. This means that adding no follow links to third-party sites does not help you retain page rank in your site. The only advantage a no follow may have is to deter spammers from posting many links in a public forum by limiting the no follows off-site.

To track page rank data, SEOmoz provides two tools: Domain mozRank and mozRank. The values these tools return are not numbers provided by any search engine; instead these are numbers that SEOmoz has developed that can be used to estimate the value of pages. This data is found in the Open Site Explorer report, which provides details about inbound links, number of linking root domains, and more.

This data becomes very useful when trying to understand how and why certain pages rank in the positions in which they do. These are yet more analytics you can put into a keyword research diagram to figure out exactly what your chances of a page ranking on a specific term are. Pagerank can be a very important factor, but domain rank is also important. For example, even if your site has the exact same content as Wikipedia, it is likely that Wikipedia will outrank you, simply because of the authority of its parent domain. To move past this top-ranking site, you would need to grow your page rank significantly beyond that of Wikipedia, to compensate for your less authoritative domain.

Tracking both you and your competitors’ page and domain ranks over time will also help you anticipate if a competitor may overtake you on specific key terms that are important to your overall search strategy. Anticipating issues before they arise will allow you to become proactive and ensure that you retain the ground you have gained, as well as understanding what ground you are close to gaining.

Source of Information : MASTERING SEARCH ANALYTICS MEASURING SEO, SEM AND SITE SEARCH
read more...

Tuesday, July 31, 2012

Tracking Diversity of Links

Improving link diversity is one of the best ways to improve your rankings organically. A page with high link diversity receives a variety of links from many domains, through a variety of keywords. If you’re targeting a specific term, you may want to see some synonyms for the term you hope to rank on. Tracking link diversity can be beneficial to understanding your true potential to rank on a term. Understanding the link diversity of those ranking ahead of you also helps to paint this picture.

Sites that have a high level of link diversity may be difficult to overtake, or you may find the gap is just too big. At this point, though, you should realize that ranking on a term organically is not just about one factor, but a combination of factors. Link diversity it is yet one more data point you can use to analyze the realistic opportunities you have specific to a keyword. Further, knowing how the overall domain performs based on bulk back links will be another factor to consider in determining site authority.

Running Majestic SEO’s Bulk Backlink Checker on a specific URL will show you how many links you have compared to a competitor on a specific page. Looking at a pageto-page comparison can provide greater insight at the micro level than looking at overall back links to a site. While the domain authority is important, so too is the page-specific data. Establishing both the volume of links and the anchor text will help you evaluate whether you have a chance of beating a competitor out of a search spot. Filter out all the no follow links to get a better idea of how the search engines will interpret the data. If you find that you are close in links on a site, expand to the domain authority and look at how many inbound links you have from all the sites by running a Bulk Backlinks report. Then look at the domain and page ranks to get an idea of the value of these links.

Source of Information : MASTERING SEARCH ANALYTICS MEASURING SEO, SEM AND SITE SEARCH
read more...

Saturday, July 28, 2012

Mobile IPv6 Types of Nodes

The Mobile IPv6 specifi cation defi nes three types of nodes. The fi rst type is the mobile node , which has the capability of moving around IPv6 networks without breaking existing connections while moving. A mobile node is assigned a permanent IPv6 address called a home address . A home address is an address assigned to the mobile node when it is attached to the home network and through which the mobile node is always reachable, regardless of its location on an IPv6 network. Because the mobile node is always assigned the home address, it is always logically connected to the home link. When a mobile node leaves its home network and attaches to another network, the node will get another address called a care-of address , which is assigned from the newly attached network. This network, which is not a home network, is called a foreign network or a visited network . A mobile node does not use a care-of address as an endpoint address when communicating with other nodes, since the address may change when the mobile node changes its point of attachment.

A second Mobile IPv6 node type is the home agent , which acts as a support node on the home network for Mobile IPv6 mobile nodes. A home agent is a router which has a proxy function for mobile nodes while they are away from home. The destination addresses of packets sent to mobile nodes are set to the home addresses of the mobile nodes. A home agent intercepts all packets which are addressed to the mobile node’s home address, and thus delivered to the home network on behalf of the mobile nodes.

This forwarding mechanism is the core feature provided by the Mobile IPv6 protocol. All IPv6 nodes which want to communicate with a mobile node can use the home address of the mobile node as a destination address, regardless of the current location of the mobile node. Those packets sent from an IPv6 node to the home address of a mobile node are delivered to the home network by the Internet routing mechanism where the home agent of the mobile node receives the packets and forwards the packets appropriately. For the reverse direction, a mobile node uses its home address as a source address when sending packets. However, a mobile cannot directly send packet nodes whose source address is a home address from its current location if it is away from home, since source addresses are not topologically correct. Sending a packet whose source address is out of the range of the network address of the sender node is a common technique when an attacker tries to hide its location when he is attacking a specific node. Such a packet may be considered as an attack. Because of this reason, the first hop router may drop such topologically incorrect packets to avoid the risk of the source spoofing attack. To solve this problem, a mobile node uses the IPv6 in IPv6 encapsulation technology. All packets sent from a mobile node while away from home are
sent to its home agent using the encapsulation mechanism. The home agent decapsulates the packets and forwards them as if the packets were sent from the home network.

A third type of Mobile IPv6 node is called the correspondent node . A correspondent node is an IPv6 node that communicates with a mobile node. A correspondent node does not have to be Mobile IPv6-capable, other than supporting the IPv6 protocol; any IPv6 node can be a correspondent node. Since the Mobile IPv6 specifi cation provides a backward compatibility to all IPv6 nodes which do not support Mobile IPv6, all IPv6 nodes can communicate with mobile nodes without any modification. However, as we have described in the previous paragraph, all packets between a mobile node and a correspondent node must be forwarded basically by the home agent of the mobile node. This process is sometimes redundant, especially when a correspondent node and a mobile node are located on topologically near networks. To solve this redundancy, Mobile IPv6 provides an optimization mechanism called the route optimization mechanism which a correspondent node may support. A mobile node can send packets directly to a correspondent node using the care-of address of the mobile node as a source address. The information of the home address of a mobile node is carried by the newly defined option for the Destination Options Header. Also, a correspondent node can send packets directly to the care-of address of a mobile node. In this case, the information of the home address is carried by the Routing Header.

A correspondent node may itself be a mobile node. In this case, two moving nodes can communicate with each other without terminating their sessions regardless of their points of attachment to the Internet.

Source of Information : Elsevier Wireless Networking Complete 2010
read more...

Tuesday, July 24, 2012

Mobile IPv6 Overview

Mobile IPv6 adds the mobility function to IPv6. Mobile IPv6 is specified in. An IPv6 host which supports the Mobile IPv6 function can move around the IPv6 Internet. 1 The host which supports Mobile IPv6 can change its point of attachment to the IPv6 Internet whenever it wants. If a host does not support Mobile IPv6, all the existing connections on the host are terminated when it changes its point of attachment. A connection between two nodes is maintained by the pairing of the source address and the destination address. Since the IPv6 address of an IPv6 node is assigned based on the prefix of the network, the assigned address on a given network becomes invalid when the host leaves that network and attaches itself to another network. The reason for this problem came from the nature of IP addresses. An IP address has two meanings: one is the identifier of the node and the other is the location information of the node. It would not be a big problem as long as IP nodes do not move around the Internet frequently, because, in that case, the location information would not change frequently and we could use location information as the identifier of a node. However, recent progress of communication technologies and small computers made it possible for IP nodes to move around. It is getting harder and harder to treat location information as an identifier, because the location information frequently changes.

As such the basic idea of Mobile IPv6 is to provide a second IPv6 address to an IPv6 host as an identifier in addition to the address that is usually assigned to the node from the attached network as a locator. The second address is fixed to the home position of the host and never changes even if the host moves. The fixed address is called a “ home address. ” As long as the host uses its home address as its connection information, the connection between the host and other nodes will not be terminated when the mobile host moves.

The concept of a home address provides another useful feature to a host that supports Mobile IPv6. Any IPv6 nodes on the Internet can access a host which supports Mobile IPv6 by specifying its home address, regardless of the location of the host. Such a feature will make it possible to create a roaming server. Since the home address of the roaming server never changes, we can constantly reach the server at the home address. For example, anyone could run a web server application on a notebook computer which supports Mobile IPv6 and everyone could access it without any knowledge of where the computer is located.

Source of Information : Elsevier Wireless Networking Complete 2010
read more...

Saturday, July 21, 2012

Mobile IPv6

Mobile IPv6 is a mobility support protocol for IPv6 at the network layer. The specification was standardized at the IETF in June 2004. The standardization process was quite slow compared to the basic IPv6 specification. The initial working group draft of Mobile IPv6 was submitted in 1996, which compares favorably with the first IPv6 draft specification which was proposed to the IPng working group in 1995. The reason for the delay in the standardization of Mobile IPv6 was the need to solve security issues associated with the protocol. Mobile IPv6 enables IPv6 nodes to send or receive packets whose source address does not match the network prefix to which they are currently attached. That is, nodes have to use a type of source spoofing technique. In the early version of the specification, the protocol required the use of IPsec to ensure that the source address was valid. However, when we consider the real situation — a mobile node may communicate with many other nodes for which it does not have any identification information — using IPsec is almost impossible.

The IESG rejected the proposal from the Mobile IPv6 working group to standardize the protocol specification at that time, and insisted the working group propose a procedure to securely validate the source address of a mobile node. The Mobile IPv6 working group started a discussion to solve the problem in 2000 and finally developed a loose address ownership mechanism called the return routability procedure in 2002. The specification was accepted by the IESG and published as in 2004.

The KAME project originally used the Mobile IPv6 stack that was contributed by Ericsson. The project started to implement its own Mobile IPv6 stack in 2001 during the middle of the second term of the KAME activity. KAME implemented several versions of Mobile IPv6 to follow and validate the latest specification. The code discussed in this chapter is based on the KAME snapshot released in July 2004. At that time, the specification had already been accepted as an RFC and the code was mature.

After KAME completed the first version of their Mobile IPv6 code, they started to redesign the architecture of the mobility stack. In the new architecture most of the signal processing tasks are moved to user space, compared to the first version of Mobile IPv6 where the code was implemented in the kernel. The design is similar to the BSD Routing Socket mechanism, which separates the routing information exchange and forwarding mechanisms, with exchanging routing information in the user space and forwarding in the kernel space. There are many benefits to this design. It makes it easier to develop complicated signal processing code since developers can utilize many advanced debugging programs and techniques, while the packet processing performance is not reduced, since it is done in the kernel. Extending or replacing some of the signal processing mechanisms is also easier, which makes it possible to add support for new mobility protocols or to adapt some part of the functions to user needs. Reducing the amount of kernel modification is important when we consider merging the developed code into the original BSDs.

Source of Information : Elsevier Wireless Networking Complete 2010


read more...

Wednesday, July 18, 2012

The Requirements of Mobile IP

Mobile IP allows a node to change its point of attachment to the Internet without needing to change its IP address. This is not simply a configuration simplification, but can facilitate continuous application-level connectivity as the node moves from point to point.

A possible solution to this problem would be to distribute routes through the network to declare the node’s new location and to update the routing tables so that packets can be correctly dispatched. This might, at first, seem attractive, but it is a solution that scales very poorly since it would be necessary to retain host-specifi c routes for each mobile host. As the number of mobile hosts in the Internet increases (and the growth of web access from mobile devices such as cell phones and palm-tops is very rapid), it would become impractical to maintain such tables in the core of the Internet.

The solution developed by the IETF involves protocol extensions whereby packets targeted at a mobile host are sent to its home network (as if the host were not mobile) and passed to a static (nonmobile) node called the node’s home agent . The mobile host registers its real location with the home agent, which is responsible for forwarding the packets to the host.

If the mobile host is at home (attached to its home network), forwarding is just plain old IP forwarding, but if the host is roving, packets must be tunneled across the Internet to a care-of address where the host has registered its attachment to a foreign agent . At the care-of address (the end of the tunnel) the packets are forwarded to the mobile host.

Note that this tunneling process is only required in one direction. Packets sent by the mobile host may be routed through the network using the standard IP procedures. It is worth observing that although mobile IP can be used to address any IP mobility issue, its use within wireless LANs and mobile phone networks might be better served by linklayer (i.e., sub-IP) procedures such as link-layer handoff. These processes are typically built into the link-layer mechanisms and involve less overhead than mobile IP. Such processes do, however, require that the mobile host remains logically connected within the IP subnet to which its address belongs — it becomes the responsibility of the link layer to maintain connections or virtual connections into that subnet.

An alternative to tunneling in mobile IP might be to use source routing within IP. IPv4 has been enhanced with optional extensions to support source routing. However, since the source routing extensions to IPv4 are a relatively new development and are in any case optional, many (or even most) deployed IPv4 nodes do not support them. This means that they are not a lot of use for developing mobile IP services over existing IPv4 networks. They may be of more use in new networks that are being constructed for the first time since the Service Providers can insist on these extensions from their equipment vendors.

IPv6 offers some alternatives to tunneling for mobile IP by using the routing extension header. In this way the mobile node can establish communications with its home agent and then use information learned to directly route packets to the destination, bypassing the home agent. Since this feature is built into IPv6 and so supported by all IPv6 implementations, it makes IPv6 a popular option for mobile IP deployments.

Source of Information : Elsevier Wireless Networking Complete 2010
read more...

Sunday, July 15, 2012

Operating System: TinyOS

TinyOS aims at supporting sensor network applications on resource-constrained hardware platforms, such as the Berkeley motes.

To ensure that an application code has an extremely small footprint, TinyOS chooses to have no file system, supports only static memory allocation, implements a simple task model, and provides minimal device and networking abstractions. Furthermore, it takes a language-based
application development approach, to be discussed later, so that only the necessary parts of the operating system are compiled with the application. To a certain extent, each TinyOS application is built into the operating system.

Like many operating systems, TinyOS organizes components into layers. Intuitively, the lower a layer is, the “ closer ” it is to the hardware; the higher a layer is, the “ closer ” it is to the application.

In addition to the layers, TinyOS has a unique component architecture and provides as a library a set of system software components. A component specification is independent of the component implementation. Although most components encapsulate software functionalities, some are just thin wrappers around hardware. An application, typically developed in the nesC language covered in the next section, wires these components together with other application specific components.

Let us consider a TinyOS application example — FieldMonitor , where all nodes in a sensor field periodically send their temperature and photosensor readings to a base station via an ad hoc routing mechanism. A diagram of the FieldMonitor application, where blocks represent TinyOS components and arrows represent function calls among them. The directions of the arrows are from callers to callees.

To explain in detail the semantics of TinyOS components, let us fi rst look at the Timer component of the FieldMonitor application. This component is designed to work with a clock, which is a software wrapper around a hardware clock that generates periodic interrupts. The method calls of the Timer component. An arrowhead pointing into the component is a method of the component that other components can call. An arrowhead pointing outward is a method that
component requires another layer component to provide. The absolute directions of the arrows, up or down, illustrate this component’s relationship with other layers. For example, the Timer depends on a lower layer HWClock component. The Timer can set the rate of the clock, and in response to each clock interrupt it toggles an internal Boolean flag, evenFlag , between true (or 1) and false (or 0). If the flag is 0, the Timer produces a timer0Fire event to trigger other components; otherwise, it produces a timer1Fire event. The Timer has an init() method that initializes its internal flag, and it can be enabled and disabled via the start and stop calls.

A program executed in TinyOS has two contexts, tasks and events , which provide two sources of concurrency. Tasks are created (also called posted ) by components to a task scheduler. The default implementation of the TinyOS scheduler maintains a task queue and invokes tasks according to the order in which they were posted. Thus tasks are deferred computation mechanisms. Tasks always run to completion without preempting or being preempted by other tasks. Thus tasks are non preemptive. The scheduler invokes a new task from the task queue only when the current task has completed. When no tasks are available in the task queue, the scheduler puts the CPU into the sleep mode to save energy.

The ultimate sources of triggered execution are events from hardware: clock, digital inputs, or other kinds of interrupts. The execution of an interrupt handler is called an event context . The processing of events also runs to completion, but it preempts tasks and can be preempted by other events. Because there is no preemption mechanism among tasks and because events always preempt tasks, programmers are required to chop their code, especially the code in the
event contexts, into small execution pieces, so that it will not block other tasks for too long.

Another trade-off between nonpreemptive task execution and program reactiveness is the design of split-phase operations in TinyOS. Similar to the notion of asynchronous method calls in distributed computing, a split-phase operation separates the initiation of a method call from the return of the call. A call to a split-phase operation returns immediately, without actually performing the body of the operation. The true execution of the operation is scheduled later; when the execution of the body finishes, the operation notifies the original caller through a separate method call. An example of a split-phase operation is the packet send method in the Active Messages (AM) component. Sending a packet is a long operation, involving converting the packets to bytes, then to bits, and ultimately driving the RF circuits to send the bits one by one. Without a split-phase execution, sending a packet will block the entire system from reacting to new events for a significant period of time. In the TinyOS implementation, the send() command in the AM component returns immediately. However, it is the caller’s responsibility to remember that the packet has not yet been sent. When the packet is indeed sent, the AM component will notify its caller by a sendDone() method call. Only at this time is the AM component ready to accept another packet.

In TinyOS, resource contention is typically handled through explicit rejection of concurrent requests. All split-phase operations return Boolean values indicating whether a request to perform the operation is accepted. In the above example, a call of send() , when the AM component is still sending the fi rst packet, will result in an error signaled by the AM component. To avoid such an error, the caller of the AM component typically implements a pending lock to remember not to request further sendings until the sendDone() method is called. To avoid loss of packets, a queue should be incorporated by the caller if necessary.

In summary, many design decisions in TinyOS are made to ensure that it is extremely lightweight. Using a component architecture that contains all variables inside the components and disallowing dynamic memory allocation reduces the memory management overhead and makes the data memory usage statically analyzable. The simple concurrency model allows high concurrency with low thread maintenance overhead. As a consequence, the entire FieldMonitor system takes only 3 KB of space for code and 226 bytes for data. However, the advantage of being lightweight is not without cost. Many hardware idiosyncrasies and complexities of concurrency management are left for the application programmers to handle. Several tools have been developed to give programmers language level support for improving programming productivity and code robustness. We introduce in the next two sections two special-purpose languages for programming sensor network nodes. Although both languages are designed on top of TinyOS, the principles they represent may apply to other platforms.

Source of Information : Elsevier Wireless Networking Complete 2010
read more...