Chapter 3
Handover concepts
Ambient Networks project is developing a future networking architecture, which aims to enable the cooperation of heterogeneous networks belonging to different technologies or operator domains, as presented in Chapter 2. The architecture introduces a common control space (ACS) for all networks, which comprises several Functional Areas allowing diverse implementations. Mobility management is an integral part of the Ambient Networks architecture and advanced mobility management was highlighted as one of challenges which will affect key parts of mobility solutions in Ambient Networks
Advanced handover function should cope with the new mobile heterogeneous communication requirements and concepts of Ambient Networks. So, new ideas are required to meet this challenging mobile communication scenarios. In particular, there is the necessity of a new handover model, able to accommodate in a flexible way different endpoint mobility scenarios, tailed on specific service needs, able to accommodate possible hierarchies of mobility management decisions and networks composition, and able to support different handover modes. But there is also the need and the opportunity to adopt a “Tool box” approach for handover mechanisms, as the means to both optimize signalling/processing/buffering resources and to meet specific service requirements.
handover requirements, main issues and different phases of handover process. Then the Handover Model section follows, illustrating this new idea proposed by Working Group 4 in order to accommodate in a flexible way different endpoint mobility scenarios, possible hierarchies of mobility management decisions and networks composition, and in order to support different handover modes. Finally, it is proposed the Handover Toolbox, a very useful tool in order to construct any type of handover, also between different type of networks, able to satisfy all the requirements deriving from beyond-3G scenarios, characterized by heterogeneity of networks and mobile networks able to compose.
3.1. HO requirements
On the base of SOTA analysis [1], this section illustrates the handover requirements [2] of existing technologies, considering services and related requirements, mechanisms on control/user plane, single/multiple domains.
3.1.1. Service and related requirements
Concepts, design principles and mechanisms for handover in current mobile networks are strictly related to the target reference communication services. In particular, the strict requirements in term of frame loss and delay jitter of voice services have driven to a network
based decision approach for handover, in order to provide low interruption time values (e.g., 100-150 ms for CS domain and for 2G/3G radio access systems, null for 3G UMTS soft/er handover). On the other hand, less strict jitter delay requirements for data retrieval services (e.g. Web services, e-mail service, GSM PS domains for which there is about 1 second of interruption time for data, etc.) have driven to a mobile node based decision strategy for handover or to network assisted strategy.
3.1.2. Mechanisms on control/user plane
Various mechanisms to provide the minimum degradation on service during handover are implemented into various systems. The strategies are quite different for each system. For example:
specific strategies/algorithms/mechanisms have been adopted separately for CS and PS services in 2G GSM/(E)GPRS;
in UMTS there is no distinction between CS and PS in the RAN: different services can use a same toolbox of handover strategies/ algorithms/mechanisms. When radio bearer supports both CS and PS services, the CS solution (most stringent requirements) is applied to all services. An alternative “light” solution for handover can be applied if radio bearer support only PS service.
3.1.3. Handover related delay times in IP-based system
Handover delay time has three main components (between handover decision and completion): Layer 1 (L1) related delay to have access to the radio including reception of broadcast control information, Layer 2 (L2) related delay to have a link established, Layer 3 (L3) related delay (get IP address, update of state such as MIP binding, new route creation).
3.1.4. HO impact on QoS and QoS requirements
The handover function aims to avoid service disruption and to minimize the perception of service degradation while a mobile device is moving changing the point of attachment to the radio access system. Handover effects on the specific service can be characterized by means of the following parameters:
Handover time (HO time): it’s the amount of time between handover initiation and handover completion.
Handover interruption time: it’s the amount of time between the reception/transmission of the last user frame in the old cell/access point and the reception/transmission of the first user frame in the target cell/access point.
Handover packet loss: it’s the packet loss created by the HO process. Packet jitter/packet delay variation: it’s directly related to the HO.
example, if radio transmission conditions are changing rapidly and the end-point is moving at high speed, the time required to complete the handover could be a few seconds. If the handover is done for optimization purpose, e.g., changing interface to have a better quality of service, HO time could have less stringent requirement and will not impact the present service quality.
Requirements on HO interruption time, HO packet loss rate and packet jitter are strictly related to the quality of service requirements of each application, e.g., conversational applications are sensitive to packet loss, packet delay and delay variation; TCP connection could be highly degraded by packet loss and more tolerant to packet delay and packet delay variation.
HO time and interruption time are related to the delays of different protocol layers to assign resources and on how these delays are combined in the handover procedure. Additionally, there could be necessity of additional procedures during HO such as security, authentication, authorization, etc.
With respect to protocol layer delays:
L1 delays are related to synchronization on radio access physical layer and reception of broadcast information to access the MAC frame, etc. L2 delays are related to L2 link set-up and related access to it. L3 delays are related to L3 info reception such as IP address, IP route creation, etc.
L4-L7 delays are related to application/service, e.g., split/merging of flows, change of audio/video transcoding protocols, etc.
To optimize handover procedure, not only the single delay components should be minimised, but also their combinations.
Information about wireless/wired network resource and/or QoS can be provided to and utilized by handover algorithm, in order to support the requested QoS. Following the HO, the QoS of all flows/sessions belonging to a specific connection should remain at the same level as (or be better than) that one originally negotiated, whenever possible. Otherwise notification and re-negotiation procedures should be applied. Hence, dynamic QoS requirements should be supported and advanced handover should be flexible enough to support a wide variety of application QoS requirements, allowing diversified handover mechanisms dependent on the applications and required QoS. So, in relation to packet loss, jitter/cell delay, delay variation, etc., it is necessary to support various types of handover, including:
Fast handover: a HO that can satisfy strict delay bounds, e.g. for real-time services.
Smooth handover: a HO that can minimize packet loss.
Seamless handover: a HO with minimum perceptible service interruption.
Best effort handover: a HO with no specific QoS parameters.
Furthermore, it’s important to minimize the interruption time in QoS support for policy driven handovers. It should be possible for individual networks to implement policies that dictate how often and under what conditions a mobile terminal and a moving network should be involved in a handover. So, there is requirement for a standard mechanism which will convey the information for the individual network policies to the handover decision mechanism.
Handover should avoid the disruption of ongoing session and be able to cope with specific application requirements in regards to interruption
time, information loss and handover duration.
Handover mechanism should be designed to consider the effects of possible individual delays (i.e. from layer 1 to layer 7) and have an awareness of the their combination, in order to meet service requirements.
3.1.5. Heterogeneous access requirements
When a mobile terminal or moving network accesses a network through an access technology, it should be allowed to perform handover between heterogeneous Radio Access Technologies to visit the network through the same access technology or a different access. When a mobile terminal or moving network accesses a network through an access service provider, it should be allowed to perform cross domain handover (address, provider administrative) to visit the network through the same access service provider or a different access service provider.
3.1.6. Route optimisation requirements
It is required to select the routing paths for optimising resources. Hence, it is possible to localize the handover to the affected parts of the path in the network, or to optimize the handover in the overall network. It is important to maintain the shortest path, if possible, i.e. the cost of
the path length for user data flow should be minimized.
3.1.7. Security requirements
There should not be security degradation. Handover of terminal should not compromise the established security between terminal and network.
3.1.8. Minimization of network resources and signalling
overhead
Network resources should be minimized, hence handover processing load should be minimized in network elements and mobile terminals. Number and length of signalling messages should be minimized in networks and over air interfaces, eliminating unnecessary signalling complexity. This true also for collective handover, such as public transportation, and for handover of moving networks. Best balance between signalling load reduction and processing complexity should be achieved. Furthermore, ping-ponging effects should be avoided.
3.1.9. Other requirements for handover
During handover process it should make use anything available useful, e.g.: radio channel quality estimation, QoS assessment, traffic load
measurements.
It’s necessary to support handover of IP-based services and bearer to and from PS domains of legacy 2G and 3G networks, such as to support various categories of handover (i.e. hard handover and soft handover), or to support various HO types, HO mechanism and HO redirection. HO types could be inter interface, inter-device, inter-point of attachment, inter-middlebox. HO mechanisms could be planned, unplanned, network initiated, network controlled. It’s also important to assure support for user initiated and network initiated handover. But the handover procedures on terminal side shall be topology independent: mobile should not be assumed to have any prior knowledge of network topology.
Handover signalling and routing should support context transfer, that is the capability of preserving or obtaining connection with a certain QoS and connectivity of routing matrices.
Under normal operations, user should not be aware of handover within a single ambient network wireless network, but the handover decision should take into account user preferences (e.g., cost reduction, maximization of quality, etc).
Detection of the attachment to the new link must be possible.
Handover should be possible for unicast, multicast and broadcast service.
Handover architecture should be scalable.
3.2. Phases during a handover process
This section shows the three main phases characterizing a handover process: its initiation, its decision and its supervision.
3.2.1. Handover initiation
Handover initiation is the function that decides if the handover is needed and if it should be started. In current mobile networks, there is a single point of handover initiation: BSS for 2G GSM CS domain, either mobile or BSS for 2G (E)GPRS CS domain, either mobile node or RAN in 3G UMTS, mobile devices in IEEE 802.x, etc.
3.2.2. Handover decision
Handover decision is the function that decides the new target access point. The distinction between handover initiation and handover decision in handover process allows support of hierarchies in mobile communication systems. The element who recognizes that handover shall be performed, could not have all knowledge to decide which is the next better access point into approach. In this case, decision is demanded to the element higher in hierarchy. Examples of splitting handover initiation and handover decision are implemented in the CS domain of GSM and in the PS domain of GPRS system. Additionally,
mechanisms like NACC (in GPRS) allow the handover decision to be taken jointly by all involved parties, considering as much relevant information as possible during HO process.
3.2.3 Handover supervision
Handover supervision is the function in charge of executing handover itself till the completion and to apply all commands on control and user plane in order to realize it. The distinction between handover decision and handover supervision applies an additional grade of flexibility to the system. Current mobile systems have a single point of handover supervision, either in mobile device, access network or core network. In particular, for GSM CS domain, handover initiation element could be different from handover supervision element.
3.3. A new Handover Model
Handovers in traditional mobile networks are about maintaining the call/session for a mobile user with minimal or no impact on user service(s). They are mainly driven by degradations in radio transmission signalling. In new heterogeneous domain and multi-technology mobile networks, handover request could be driven by other needs such as cost reduction criteria, network resource optimization, service related requirements, etc. Thus, handover could become a
critical issue if not done in an optimized way. The main objective is therefore to define concepts and functions with the aim to realize handovers characterized by new multi-dimensions (multi-domain mobile networks, multi-technologies, multi-services, multi-devices, any-cast, etc). Furthermore it is necessary to support novel requirements that are emerging due to the proliferation of mobile communication services.
Ambient Networks project is developing a future networking architecture, which aims to enable the cooperation of heterogeneous networks belonging to different technologies or operator domains, as presented in chapter 2. The architecture introduces a common control space (ACS) for all networks, which comprises several Functional Areas allowing diverse implementations. Mobility management is an integral part of the Ambient Networks architecture and advanced mobility management was highlighted as one of challenges which will affect key parts of mobility solutions in Ambient Networks
Advanced handover function should cope with new mobile communication requirements and concepts of Ambient Networks. The main new aspects introduced not covered in today mobile communication systems for the handover functions include support for different mobile entities (physical terminal, session, applications, routing groups) and the handover granularity required for separate handovers at the flow/session level; support of a wide range applications with various QoS requirements and transmission modes (unicast, multicast, broadcast) received, transmitted and forwarded with heterogeneous radio technologies and networks.
With the mentioned heterogeneous requirements, it is not possible to relay on specific mechanisms/characteristics of a certain technology
such as software handover, pre-reservation of resources, a certain addressing scheme and the related features (e.g. IPv4/IPv6).
So, new concepts are required to meet this challenging mobile communication scenarios. In particular, it occurs a new functional model, able to accommodate in a flexible way different endpoint mobility scenarios (physical terminals, application, session, routing groups, users), tailed on specific service needs, able to accommodate possible hierarchies of mobility management decisions and networks composition, and able to support different handover modes (planned/unplanned handover, endpoint/network initiated, etc). But there is also the need and the opportunity to adopt a “Tool box” approach for handover mechanisms, as the means to both optimize signalling/processing/buffering resources and to meet specific service requirements.
3.3.1. Handover Model description
The proposed generic Handover Model [3] is targeting all mobility cases in the Ambient Network project, therefore taking into account every possible handover type, mechanism and characteristic. The model includes a number of HO steps, from Trigger Collection and Pre-Computation to HO Execution. Additionally, each HO step is described through a group of related handover functions.
Each HO step could be realised by the coordination of different physical devices of one or different domains, as well as a group of functional steps could be realised by a single physical device.
The presented HO Model is valid during the whole lifecycle of a handover: in this sense all HO steps may have a role during HO preparation, initiation, supervision and post-HO optimisations.
In the following, a description of the HO Model is given. Conceptually, the HO-FA takes triggers and input from other FAs, e.g. Context Management and makes a decision about the HO, including HO type (L3, L2, device, mobility end-point/naming entity) and chooses a tool to be used for constructing an appropriate handover. Then, it supervises and coordinates to all the HO commands, performs the HO (executes it) with the possible cooperation of ACS functions. Optionally, it does some post-HO optimisation.
Trigger collection and precomputation HO Decision and tool selection HO Execution (either pre/exe/post)
•Collection and identification of various mobility triggers •Classification of those triggers according to criteria and policies •Precomputation of different triggers: addition of more information like timestamps or priorities.
•Signalling between involved ANs, negotiation and info exchange (access capabilities, characteristics, service availability, route discovery, …)
•Selection of the best option for HO (AP, route, ..) and respective HO tools, including
modification/adaptation of the data flow to the new access characteristics, session reconfiguration, data buffering / forwarding, resource reservatoins, ... •HO supervision and related decisions. •Planning of further actions like route optimisation. •Maintenance of HO history.
•Reservation of radio/network resources •HO Context transfer (L3, L2, L1) •Signalling to link (L2) creation •Route creation (anchoring, bicasting…) •User plane HO mech. (e.g., tunnelling, storage, duplication, retransmission, forwarding, etc)
•Update of state (IP address, ..)
HO steps • … HO functions HO Tools Selected by Used by TRG_FA HO_FA Trigger collection and precomputation HO Decision and tool selection HO Execution (either pre/exe/post)
•Collection and identification of various mobility triggers •Classification of those triggers according to criteria and policies •Precomputation of different triggers: addition of more information like timestamps or priorities.
•Signalling between involved ANs, negotiation and info exchange (access capabilities, characteristics, service availability, route discovery, …)
•Selection of the best option for HO (AP, route, ..) and respective HO tools, including
modification/adaptation of the data flow to the new access characteristics, session reconfiguration, data buffering / forwarding, resource reservatoins, ... •HO supervision and related decisions. •Planning of further actions like route optimisation. •Maintenance of HO history.
•Reservation of radio/network resources •HO Context transfer (L3, L2, L1) •Signalling to link (L2) creation •Route creation (anchoring, bicasting…) •User plane HO mech. (e.g., tunnelling, storage, duplication, retransmission, forwarding, etc)
•Update of state (IP address, ..)
HO steps • … HO functions HO Tools Selected by Used by TRG_FA HO_FA Figure 15: HO model
3.3.1.1. “Trigger Collection and Pre-computation ” Step
The process for deciding whether or not to perform a handover starts by collecting the different triggering events that could lead to a handover [4]. To enable development of mechanisms for handover decision, all trigger groups were classified based on six different criteria. For each particular mobility case or environment, the classification allows identifying and concentrating only on those events that are deemed necessary to monitor and react. For example, reception of a forcing event via ASI indicates an explicit handover command from user or application. For each case it is possible to select a suitable set of classification criteria for identifying those trigger events that are complying with particular user and operator preferences or policies. The classification criteria are presented in table below :
Criteria Classes Description
Event source
ACS An event is received from the local ACS, i.e.
from any of the Functional Areas (FA) in the local ACS. Further sub-classification could be done based on the FAs.
ANI An event is generated in some other AN, and
is delivered to local ACS via ANI.
ASI An event is generated in higher layers and
received via Ambient Service Interface (ASI).
ARI An event is received via ARI.
Event type Predicting An event that does not imply need for
handover yet, but might be a hint of the need for handover in near future and consequently allow anticipation.
Triggering An event that alone may lead to a handover.
Other concurrent or earlier events may affect the handover decision and procedure.
Forcing An event that mobility management has no way to optimise or negotiate. This forces a handover execution. Otherwise
communication will be interrupted
Periodic An event occurs periodically with a constant
time interval.
Asynchronous, on-demand
An event may occur at any time, but is generated on-demand due to request by the system.
Event frequency
Asynchronous, self-generated
An event may occur at any time in a self-generated manner
Event
Persistence
Volatile An event may occur and disappear in the
sense of transient event
Non-volatile Once the event occurs it stays in the same status and doesn't disappear.
Event Time constraint
Real-time An event that must be raised within a certain timeframe
Non real-time An event that can be raised at any time without time constraint
Physical location
Communication endpoint moves within the same radio access technology (traditional mobility)
Access technology
Communication endpoint moves from one RAT to another (e.g. vertical handover)
Address space Communication endpoint moves between
networks/devices, which use different address space (e.g. IPv4 -> IPv6)
Security domain
Communication end-point moves over a trust border between network domains (e.g. from public to private WLAN, both of which might be operated by same organization)
Provider domain
Communication endpoint moves between networks/devices operated/owned by a different provider (e.g. roaming)
Related mobility dimension
Device properties
Communication endpoint moves from a device to another, hence the system properties of the host device may change dramatically (e.g. inter-device handover)
Time Communication endpoint does not move spatially, but on-going communication is suspended for a while and resumed
afterwards (e.g. if a user wants to pause the connection for a while, or for a temporary loss of connectivity).
Table 1: Classification criteria for triggering events
The different trigger groups can be used for requesting information on certain triggering events from related entities in the AN architecture. An implementation of mobility control space could make use of this classification by deciding about handover initiation depending on if the trigger event is received via ARI or from the ACS: the former could indicate that the HO mechanism needs to support legacy network, while the latter could reveal that the network is AN compatible. In addition, trigger classification can be utilised for identifying triggering events that are critical for mobility management. For example, all forcing triggers with real-time constraint would fall in this class. Receipt of such a trigger would require a quick initiation of HO procedure and fast mechanisms to be used, while other types of triggers may allow using of more complicated approaches.
The actual handover decision and the selection of appropriate mechanisms for HO execution can partially rely on a suitable set of triggers selected according to the classification. In addition, in many cases mobility in different dimensions can be initiated based on different sets of triggers, and suitable handover mechanisms can be selected accordingly. From the triggers received, it is possible to derive the information on whether the mobile entity is moving within a single network, or crossing technology boundaries, and whether the
addressing mechanism, trust domain, and/or provider domain should be changed as well. Triggers may also give a hint about if the communication endpoint should be moved from a device to another on the fly. These different kinds of movements may occur independently or as coupled together. Hence the mobility can be seen to take place in multiple orthogonal dimensions, called “mobility dimension”.
3.3.1.2. “Handover Decision & Tool Selection" Step
The main part of the Handover Model is the handover decision step. Corresponding to various types of possible handovers in the AN network, the HO decision step needs to recognize the triggers coming from the different events, to classify them according the relevance in regards to the HO, and to use the information from the Context Provisioning FA in order to apply user, network service or other preferences [5]. Then it is necessary to decide on the handover, choosing the appropriate HO tool available, i.e. the definition of the mechanisms and peculiarities dictating how the handover should be performed: see Handover Toolbox description in section 3.3.2.1.
In this functional step the HO is decided on the base of all relevant information and possibly thanks to a negotiation between the involved entities. A signalling between different entities is therefore expected in this step, e.g. for the sake of path discovery, media control and exchange of information relevant to the HO in general. Information such as service requirements and QoS, context, networks information and user/operator preferences and policies are examples of the
information that needs to be considered.
The handover decision process outcome is to indicate the necessity (or less) of a handover operation, together with the information about the mobility dimension in which to perform the handover and the HO tools which should be used. This process should take place when a certain set of triggers has occurred. The main concepts involved in this area are: collection of triggering information, creation of production rules for HO decision and conflict resolution related to handover.
The decision to perform a handover should be based on global and local policies, rules that are based on the triggering events that take place and conflict resolution operations in case that those same rules are conflicting in their outcome. These policies should include user preferences on costs, security, QoS as well as operator policies in the same areas that could determine the final outcome of the decision process. After the triggers have been gathered, the Handover Management FA should evaluate them according to the HO production rules and then proceed to check for conflict resolution and finally determine the mobility dimension that should handoff (or should not handoff) and the tools necessary to perform – possibly - a seamless handover (see Figure 16). Once this has been determined, the outcome of the decision must be notified to the HO execution function which will implement the handover decisions.
The HO process consists of HO preparation, main execution, supervision and post-HO optimisations. In all these phases the HO Decision Engine is active, and it remains active until the handover process is not concluded.
During HO supervision in case of problems it could be need to block the running handover and start another one, or modify some details in
course of action.
During post-HO optimisation a number of actions could be decided: e.g. a route optimisation, a packet forwarding, a change in the QoS of media flow and potentially more.
Figure 16: Detailed Functional steps involved in HO decisions
3.3.1.3. “HO execution (either pre/ex/post)” Step
In this step the handover decisions are executed [6]. HO execution can be active at various moments during the HO process. In fact, during HO preparations, context transfer mechanisms are solicited; during the main HO execution, user plane HO functions are configured and services from other functions such as security and link layer establishment are required; during post-HO , optimizations or change
of data flow characteristics may take place.
3.3.2. The Handover Toolbox (HT)
The Handover Toolbox [7] is a set of elementary handover mechanisms/ characteristics/commands (coming from SOTA and requirements analysis) that could be used to describe/construct a generic handover.
The HT could be used by a (centralised or distributed) function that takes the handover decision. This function selects the sequence of appropriate HO mechanisms/characteristics/commands to be applied to a specific HO needs.
The HT is very flexible and capable to cover all existing and future kinds of handovers, allowing the construction of handoffs by combining handover characteristics that could classically belong and be inherited from different existing and future systems and handover types. In this way it carries in itself the generalisation among different technologies that is the most characterising factor of the AN project. To describe the different elementary handover mechanisms/ characteristics/ commands, a modular structure is adopted that allows to easily add new commands or to remove obsolete commands without troubles.
A Handover Toolbox description is provided in the next section. It should be considered as a high level concept which should be applicable to all AN scenarios.
3.3.2.1. HT description
The handover toolbox approach allows to meet specific service requirements, to optimize network resources (signalling/processing/ buffering) and to go towards the challenging requirements for handover such as the support of various HO types (inter interface, inter-device, inter-point of attachment, inter-middlebox), HO mechanisms (planned/unplanned, network initiated/controlled) and HO specific feature (e.g. HO redirection).
In this section some important term definitions are assumed (see the appendix). The term “<network>” (or AN) indicates an atomic ambient network (not composed by other ambient networks, i.e. a single device or an infrastructure element), or a set of atomic ambient networks. An AN could specify one or more available “accesses” (wired o wireless) for usage by one or more applications/services. An ambient network HO could handover entire ANs, flows or sessions. A session is formed by one or more flows (each one identified by a name/descriptor and characterized by a certain QoS) between two ANs (or even more that two, in case of multicast/broadcast sessions). Based on many factors, there could be the necessity to reconfigure one or more flows composing a session, maybe involving other ANs. The aim is to optimise what is available in that moment, for the purpose to reduce/avoid packet loss (seamless HO) and to maintain/improve the quality of a certain services. So, the communication between two ANs could involve other ANs forming an “active route”, that is a set of available routes used at the same time (this concept is quite similar to the IP routing). The edges of each link of the route (link is the direct connection – without any intermediate AN - between two ANs) can
establish the QoS, transmission diversity type if they can use two or more accesses, and if it is necessary to get an action (Register/De-register, Authentication/De-Authentication or Authorisation/De-Authorisation). In any moment, each AN could request information for monitoring the network status and for other purposes either before or during the HO, e.g. on mobility, security, network-resources, access-capabilities, QoS-service, session-characteristics, etc.
It follows a description of each HT command. Register / De-register
Before performing a handover, an AN could request to register itself (e.g. to register its new CoA or to register a service identifier) to another AN, with the purpose to be already known before the handover, so to retrieve faster access to the resource.
Authentication / De-Authentication
Before performing a handover, an AN could request to authenticate itself towards other ANs, with the purpose of its identity being already recognised and validated before the HO. It could be useful in wireless AN composition, where authentication is needed. Again, access to the resources can result faster when this procedure is carried on in advance. Authorisation / De-Authorisation
Before performing a HO, an AN could need to request the authorisation to use one or more ANs (often accompanied to authentication and registration). Again, it could be useful in wireless AN composition, where authorisation is needed (e.g roaming between wireless AP). When performed in advance, it allows faster access to the resource.
Session flow reconfiguration
A single flow could be split into two or more flows. In the same way, two or more flows could be aggregated in a single flow. How to perform the session flow reconfiguration depends on many factors, as single device capabilities, user preferences or service requirements. Change data flow characteristics
Based on service requirements, device capabilities and user preferences, it could be useful (or necessary) to change the data flow characteristics (e.g. packet loss rate, data rate or max delay).
Discover new accesses and routes
In traditional wireless networks, a device can discover new available AP(s) (or devices), but it can obtain only L2 information, and then through message exchange (such as in FMIPv6) obtain also IP info about those AP(s). This command is an enhancement of the traditional “SCAN” operation in the WLAN technologies, because it allows discovering more info useful for its actual applications/services. For example, a device could discover info about available services to that AP(s) discovered, the available QoS for a certain (or a set of) service(s), the best route to maintain (or to improve) the actual communication. This command and the info exchange command could be used together.
Reserve/Book / Release resources
A <network> could request to reserve/book/release resources for a particular flow on active route, to obtain the needed resources, if possible in a certain amount of time.
Change active paths
A flow communication (or more) between two ANs, could include, at the same time, several intermediate ANs. So, it could be useful to change the existing active route(s) to improve (or to maintain) the communication.
Start buffering
To prevent data loss, some applications/services could request to buffer incoming packets during the HO execution. This command is connected to forward command, because after buffering, it occurs to forward the buffered packets. In some cases, this command is connected to the flush command to free up the unused data.
Forward
If before was used the start buffering command, then it is necessary to use this command. It is also a deliver command, because can forward the incoming data for one or more flows through several active routes (if possible in a certain amount of time). For example, in a certain amount of time, a user that is viewing a soccer match on his mobile phone could decide to forward the stream to his home video recorder to record this match.
Flush
This command should be used after using the buffer command: it frees the buffered data, if not more necessary.
Info exchange
An AN could request info about one or more ANs, before to perform a HO. This command could be used together to discover new accesses
and paths command. Use security mechanism
It’s very important to use security mechanism in wireless network, to prevent privacy violation or malicious intrusions.
MM context update
This command allows obtaining info about the network status (e.g. congestion) and the HO history for each <network>, in order to prevent undesired effects (e.g. ping-ponging).
