WO2017176177A1

WO2017176177A1 - Requesting migration of a service session

Info

Publication number: WO2017176177A1
Application number: PCT/SE2016/050284
Authority: WO
Inventors: Vinay YADHAV; Amir ROOZBEH; Johan Rune; Jonas Pettersson
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2016-04-05
Filing date: 2016-04-05
Publication date: 2017-10-12

Abstract

A method in a first service network node for requesting migration of a service session to a second service network node. The service session is associated with a communication device in a communications network. The service session is provided to the communication device by a service application running in the first service network node. The first service network node receives (601, 605) from the second service network node an indication that the second service network node is able to admit migration of the service session. The first service network node then requests (608) migration of the service session to the second service network node based on the received indication.

Description

REQUESTING MIGRATION OF A SERVICE SESSION

TECHNICAL FIELD

Embodiments herein relate to a first service network node, a second service network node and methods therein. In particular, they relate to requesting migration of a service session in a wireless communications network.

BACKGROUND

Examples of wireless communication systems or wireless communication networks are Long Term Evolution (LTE), Universal Mobile Telecommunications System (UMTS) and Global System for Mobile communications (GSM), developed in the 3rd Generation Partnership Project (3GPP).

A cellular communications network covers a geographical area which is divided into cell areas, wherein each cell area being served by an access node such as a base station, e.g. a Radio Base Station (RBS), which sometimes may be referred to as e.g. "eNB", "eNodeB", "NodeB", "B node", or BTS (Base Transceiver Station), depending on the technology and terminology used. The base stations may be of different classes such as e.g. macro eNodeB, home eNodeB or pico base station, based on transmission power and thereby also cell size. A cell is the geographical area where radio coverage is provided by the base station at a base station site. One base station, situated on the base station site, may serve one or several cells. Further, each base station may support one or several communication technologies. The base stations communicate over the air interface operating on radio frequencies with communication devices within range of the base stations.

Communication devices such as terminals are also known as e.g. User Equipments (UE), mobile terminals, wireless terminals and/or mobile stations. These terms will be used interchangeably hereafter. Communication devices are enabled to communicate wirelessly in a cellular communications network or wireless communication system, sometimes also referred to as a cellular radio system or cellular networks. The

communication may be performed e.g. between two communication devices, between a communication device and a regular telephone and/or between a communication device and a server via a Radio Access Network (RAN) and possibly one or more core networks, comprised within the cellular communications network. Communication devices may further be referred to as mobile telephones, cellular telephones, laptops, tablets or surf plates with wireless capability, just to mention some further examples. The communication devices in the present context may be, for example, portable, pocket-storable, hand-held, computer-comprised, or vehicle-mounted mobile devices, enabled to communicate voice and/or data, via the RAN, with another entity, such as another communication device or a server.

A concept that is gaining increased attention is the possibility to deploy clouds for execution of services and/or applications closer to the communication devices in cellular networks. The purpose of deploying these clouds is both to reduce the amount of transport network bandwidth being used and to achieve a better performance of the communication device, e.g. through reduced roundtrip delays and possibly smart interactions between the cloud and the network functionality. For example, frequently requested content stored in or streamed from the cloud may be detected from a particular region or geography and then the content may be moved closer to the communication devices that request the content.

Another example is when the movement of a communication device is detected based on where the communication device connects to the network and then the content delivery may be migrated or moved to a cloud closer to the user.

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources, e.g. networks, servers, storage, applications, and services, that may be rapidly provisioned and released with minimal management effort or service provider interaction.

Clouds for execution of services, i.e. service clouds, come in various forms, e.g. "Platform as a Service" (PaaS) or "Infrastructure as a Service" (laaS). In the most basic cloud-service model— and according to the IETF (Internet Engineering Task Force)— providers of laaS offer computers— physical or (more often) virtual machines— and other resources. laaS refers to online services that abstract user from the detail of infrastructure like physical computing resources, location, data partitioning, scaling, security, backup etc.

The capability provided to the consumer by PaaS is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment. Services, such as video streaming and gaming, provided to the communication devices, such as UEs, may be placed locally in a service network node inside a base station to enhance quality of experience as perceived by the communication device, and in the end by a user. This may be achieved by using local knowledge to optimize the Transmission Control Protocol (TCP) performance. Local knowledge may for example mean local knowledge of popular videos being watched, applications (apps) that are popular and frequently used in a particular area, local knowledge of a large number of users using gaming applications in a local area, etc. Placing services locally in a service network node inside a base station also reduces the network traffic that flows in the backhaul network.

An issue when placing services inside the base station is that of mobility, since a connection between the communication device and the service session running inside the base station has to be terminated and re-established with another base station while the communication device is handed over from a first to a second base station. This may result in the communication device experiencing a disruption in connection with service.

Figure 1 illustrates a UE 130 moving from a first base station 11 1 towards a second base station 1 12. A first service network node 121 is connected to the first base station 11 1 , while a second service network node 122 is connected to the second base station 1 12.

A migration of a service session, e.g. in the form of migration of the context of the service session, from one local cloud to another in order to follow a moving

communication device, e.g. when the local clouds are deployed at the base station, e.g. eNB, sites, may be denoted session migration. In Figure 1 a service session 425 is migrated from the service network node 121 to the second service network node 122.

Another terminology for service session also used in this context is an application session.

Figure 2 shows an example network architecture supporting session migration. In this figure, a communication device, such as the UE 130, may move between different regions, 1-4. A region determines the area in which one Local Service Cloud (LSC) may provide services. In Figure 2, LSC 1 provides services in region 1 , LSC 2 provides services in region 2, LSC 3 provides services in region 3 and LSC 4 provides services in region 4. Such a region may correspond to the area covered by one radio access network node, such as an eNB or an RNC, but it may also correspond to an area covered by multiple radio access nodes, such as region 1 + region 2. When the communication 5 device moves from the source region to another region, i.e. to the destination or target region, the service session provided to the communication device and located in the LSC is also transferred from the source LSC (i.e., serving the source region) to the destination LSC (i.e., serving the destination region).

The LSCs may be located at different hierarchical levels, e.g. at a base station site, 10 a hub site and/or a central site, e.g. located above the (S)Gi interface. A higher

hierarchical cloud may cover the same area as multiple service networks on a lower hierarchical level. In Figure 2 LSC N is at hierarchical level 2. The (S)Gi interface refers to the interface between a Packet Data Network (PDN) Gateway and the external network.

15 The general process of Admission Control (AC) within the session migration concept occurs at the time of handover of the communication device. Admission control in this context may be defined as the process of verifying if an incoming session may be allowed to be migrated into the destination LSC or not.

In fact, an AC request will be sent to the destination LSC as one of the handover

20 methods. In this way, the target LSC will process the AC request and provide the

response as shown in Figures 3a and 3b. Figures 3a and 3b illustrates an example in which the service network nodes are LSCs, the radio network nodes are eNBs and the communication device is a UE. Each eNB comprises a Radio Network Layer (RNL) and a Session Migration Service (SeMS).

25 Figure 3a illustrates a scenario when the admission control is permitted. If

admission control fails, the source LSC needs to determine another LSC to perform AC and move the UE's session context. This is illustrated in Figure 3b.

Actions 301-309 relate to both Figure 3a and 3b.

In action 301 the UE 130 receives a reference signal from the second base station 30 1 12. The UE 130 performs measurements related to the reference signal, and sends a measurement report to the first base station 11 1 in action 302.

In action 303 the RNL of the first base station 11 1 takes a decision to handover the UE 130 to the second base station 112. In action 304 a trigger for service migration is sent internally from the RNL to the SeMS in the first base station 1 11. In action 305 the first base station 11 1 communicates with the first service network node 121 , denoted as Local Service Network (LSN) signaling in Figure 3a and 3b, to prepare for service migration. In action 306 the SeMS in the first base station 1 11 sends service migration signaling and an admission control request to the RNL in the first base station 1 11. Action 306 may be performed using Media Independent Handover (MIH) and Context Transfer Protocol (CXTP).

In action 307 the first base station 11 1 sends a handover request to the second base station 1 12. In action 308 the RNL in the second base station forwards the service migration signaling and the admission control request to the SeMS in the second base station 1 12. Action 307 and action 308 may be performed using MIH and CXTP.

In action 309 a decision about admission control is taken. The process of admission control involves verifying if there are necessary and sufficient resources available at the destination LSC to admit an incoming service session. Resources may be physical resources such as computing power (CPUs), memory and storage, and application resources such as required applications or contents. The base station and the LSC may verify different resources respectively. At the eNodeB level the decision is taken if the incoming UE may be admitted to the target eNodeB. In the target LSC the admission decision is taken based on the availability of the physical resources and/or application resources needed for the service session. Since the LSC may exist without the eNodeB, especially the LSCs at level 2 and higher in the hierarchy, it is only in the case where the UE is moving to another eNodeB that the SM signalling in action 308 becomes relevant. If there is no eNB involved it is only the AC request that is signalled from RNL to SeMS in action 308.

Actions 310a to 312a relate to Figure 3a, i.e. relating to the scenario when the admission control is permitted in action 309. Then in action 310a the second service network 122 and the second base station 112 communicate with LSN signaling and finalize the service migration. In action 31 1a the SeMS of the second base station 1 12 sends service migration signaling and an admission control request acknowledge to the RNL in the second base station 112. The second base station 1 12 then sends a handover request acknowledge, which comprises an acceptance, to the first base station 11 1 in action 312a.

Action 312a may be performed using MIH.

Actions 310b to 312b relate to Figure 3b, i.e. relating to the scenario when the admission control is rejected in action 309. In action 310b the second base station 112 sends a handover request acknowledge, which comprises a rejection, to the first base station 1 11. Action 310b may be performed using MIH.

The first base station 1 11 and the first service network node 121 then selects a new target service network node for migration of the service session. In action 312b a new admission control process is started.

Some present solutions for session migration may be time consuming, partly depending on the amount of application context to migrate. An application context is the information that an application stores that pertains to a communication device, such as a user equipment, that is accessing the application. For example if the application is a video streaming server, then the application context that belongs to a user equipment that is connected to the application may be: 1) the content the user equipment is accessing, e.g. defined by file name of the video, 2) the offset in the video stream that the user equipment is currently downloading, e.g. specified in seconds.

The time needed for the session migration may cause disturbance to the application execution in the communication device and may in the end reduce the performance of the communication device. In addition, if the session migration is synchronized with the handover of a communication device which is using an application in the LSC, the delay may compromise the reliability of the handover, i.e. the risk for handover failure may increase.

The session migration may be even more time consuming when admission control fails, since then the source LSC needs to determine another LSC to perform AC and move the UE's session context.

Consequently, there is a need to find ways of facilitating session migration and reducing or avoiding the excessive delays.

A prior art document relating to migration of a service session is WO2015/084230

A1.

SUMMARY

It is therefore an object of embodiments herein to provide an improved way of requesting migration of a service session in a wireless communications network. According to a first aspect of embodiments herein, the object is achieved by a method in a first service network node for requesting migration of a service session to a second service network node. The service session is associated with a communication device in a communications network. The service session is provided to the

communication device by a service application running in the first service network node.

The first service network node receives from the second service network node an indication that the second service network node is able to admit migration of the service session.

The first service network node then requests migration of the service session to the second service network node based on the received indication.

According to a second aspect of embodiments herein, the object is achieved by a first service network node configured to request migration of a service session to a second service network node. The service session is configured to be associated with a communication device in a communications network. The service session is configured to be provided to the communication device by a service application configured to run in the first service network node.

The first service network node is configured to receive from the second service network node an indication that the second service network node is able to admit migration of the service session.

The first service network node is further configured to request migration of the service session to the second service network node based on the received indication.

According to a third aspect of embodiments herein, the object is achieved by a method in a second service network node for for assisting a first service network node in requesting migration of a service session to the second service network node. The service session is associated with a communication device in a communications network. The service session is provided to the communication device by a service application running in the first service network node.

The second service network node sends to the first service network node, an indication of whether or not the second service network node is able to admit migration of the service session. The indication is sent without having received from the first service network node a prior request to migrate the service session. According to a fourth aspect of embodiments herein, the object is achieved by a second service network node configured configured to assist a first service network node in requesting migration of a service session to the second service network node. The service session is configured to be associated with a communication device in a communications network. The service session is configured to be provided to the communication device by a service application configured to run in the first service network node.

The second service network node is configured to send to the first service network node an indication of whether or not the second service network node is able to admit migration of the service session. The second service network node is configured to send the indication without having received from the first service network node a prior request to migrate the service session.

Since the first service network node receives from the second service network node an indication that the second service network node is able to admit migration of the service session, and further requests migration of the service session to the second service network node based on the received indication the probability of failure of acceptance control at the time of handover is reduced. Embodiments herein enable faster and more reliable migration of service sessions by reducing the probability of failure of admission control at the time of handover. That is, they reduce the probability that a request for admission control will not be permitted at the second service network.

For instance, if the first service network node, such as a source LSC, knows in advance that a certain second service network node will not accept the admission control request, e.g. since the particular second service network node has sent an indication that the second service network node is not able to admit migration of the service session, the first service network node will not try to transfer the service session to that particular second service network node at handover time.

Instead, it will try another alternative second service network node that has indicated that it is able to admit migration of the service session, e.g. by accepting a proactive request for admission control. The proactive request may also be referred to as a preliminary request or a proactive preliminary request. The alternative second service network node may for example be a hierarchically higher second service network node, such as a hub site LSC, covering the cell/site/node/location the communication device will be handed over to.

Additionally, if the first service network node requested proactive admission control, then at the time of the actual handover, i.e. when the actual admission control need to be performed, the destination, i.e. target, second service network node may process an admission control and/or installation of the transferred service session faster, since the target second service network node has been informed about a potential handover and session migration in the form of the proactive request for admission control. As a result, the session migration time will be reduced.

Embodiments herein enable seamless migration of a service session running in a distributed Cloud to another distributed Cloud.

A more general advantage with embodiments herein is that they enable service providers to host services, for example video streaming, closer to the communication devices, for example inside a base station. This reduces the latency between the communication devices and the service which may result in enhanced quality of experience. Placing the services closer to the communication devices also reduces the network traffic load between the base station and an anchor point for mobility, such as a Serving Gateway.

BRIEF DESCRIPTION OF THE DRAWINGS

Examples of embodiments herein are described in more detail with reference to attached drawings in which:

Figure 1 is a schematic block diagram illustrating a wireless communications network according to prior art.

Figure 2 is a schematic block diagram illustrating a network architecture supporting

session migration according to prior art.

Figure 3a is a signaling diagram illustrating a method for migration of a service session in conjunction with handover of a UE according to prior art. Target LSC admits session migration.

Figure 3b is a signaling diagram illustrating a method for migration of a service session in conjunction with handover of a UE according to prior art. Target LSC rejects session migration. Figure 4 is a schematic block diagram illustrating embodiments of a wireless

communications network.

Figure 5 is a combined signaling diagram and flow chart illustrating a method for

migration of a service session according to embodiments herein.

Figure 6a is a flowchart depicting embodiments of a method for migration of a service session in a first service network node.

Figure 6b is a flowchart depicting further embodiments of a method for migration of a service session in a first service network node.

Figure 7 is a flowchart depicting embodiments of a method for migration of a service session in a second service network node.

Figure 8 is a schematic block diagram illustrating further embodiments herein.

Figure 9 is a flowchart illustrating further embodiments herein.

Figure 10 is a schematic block diagram illustrating further embodiments herein.

Figure 1 1 is a flowchart illustrating further embodiments herein.

Figure 12 is a flowchart illustrating further embodiments herein.

Figure 13 is a schematic block diagram illustrating further embodiments herein.

Figure 14 is a flowchart illustrating further embodiments herein.

Figure 15 is a schematic block diagram illustrating embodiments of a first service network node.

Figure 16 is a schematic block diagram illustrating embodiments of a second service network node.

Figure 17 is a schematic block diagram illustrating interfaces used for session migration. DETAILED DESCRIPTION

As part of developing embodiments herein, a problem will first be identified and discussed.

As mentioned above, a problem with the present solutions for session migration is that they may be time consuming.

Furthermore, it is not certain that the LSC at the target site, i.e. the candidate target

LSC for migration of the session, has enough resources available to serve the session. If the target LSC rejects the request for migration, e.g. as a consequence of not having enough resources available to serve the session, the source LSC has to find an alternative LSC, e.g. at a higher hierarchical level, to migrate the service session to. This causes further delay which pronounces the above described problem. Embodiments herein address the issue of time consuming migration of service sessions between service network nodes, such as LSCs. Such service sessions may be provided by a local cloud, i.e. a LSC, integrated in or at base stations in a wireless communications network.

Embodiments herein enable faster dynamic re-allocation, i.e. migration, of a service session and/or application session associated with a communication device. The service session may also be referred to as a user session.

The re-allocation may be needed due to handover of the communication device which in turn may be due to mobility of the communication device, e.g. when it moves from one base station to another base station.

In embodiments herein, methods and service network nodes for enabling faster and more reliable migration of service sessions are described. The migration is faster and more reliable since the success rate of a first attempt of migration of the session is improved compared to prior art methods. As a consequence embodiments herein reduce latency between the user equipment and the service.

Embodiments herein will now be illustrated in more detail by a number of exemplary embodiments. It should be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present in another embodiment and it will be obvious to a person skilled in the art how those components may be used in the other exemplary embodiments. Figure 4 depicts a wireless communications network 400 in which embodiments herein may be implemented. The wireless communications network 400 may for example be an LTE/System Architecture Evolution (SAE), UMTS, GSM, any 3GPP cellular network, Wimax, or any cellular network or system.

Embodiments herein may be implemented as a Platform as a Service (PaaS). The wireless communications network 400 comprises a plurality of base stations and other network nodes. More specifically, the wireless communications network 400 comprises a first base station 411, also referred to herein as a source base station, and a second base station 412, also referred to herein as a target or destination base station. The base stations may also each be referred to as a NodeB, an evolved Node B (eNB, eNode B), an Access Point Base Station, a base station router, or any other network unit capable of communicating with a user equipment within a cell served by the base station, depending e.g. on the radio access technology and terminology used.

The wireless communications network 400 further comprises a first service network node 421 associated with the first base station 41 1 , and one or more second service network nodes 422, 423, 424.

The first service network node 421 may be a service network node, or in other words a service network, integrated in the first base station 41 1.

In other embodiments the first service network node 421 is not integrated but coupled to, e.g. connected to, the first base station 41 1. The respective one or more second service network node 422, 423, 424 may likewise be a service network node integrated in or coupled to the second base station 412.

Each of the first service network node 421 and the one or more second service network nodes 422, 423, 424 may further be a device such as a computer, Central Processing Unit (CPU) or server. The service network nodes 421 , 422, 423, 424 may each be implemented as distributed clouds, such as an LCS. Such a cloud may be a network of CPUs offering services to users. Thus each of the service network nodes 421 , 422, 423 may be an LSC.

Note also that the service network nodes 421 , 422, 423, 424 may be located at different hierarchical levels, e.g. at a base station site, a hub site and/or a central site, e.g. located above the (S)Gi interface. A higher hierarchical service network node may cover the same area as multiple service network nodes on a lower hierarchical level.

The first base station 41 1 serves a communication device 430, also referred to as a UE or a wireless device. In other words, the communication device 430 is located in a cell served by the first base station 41 1. The communication device 430 may

communicate with the first base station 41 1 within the cell.

The communication device 430 may e.g. be a mobile terminal or a wireless terminal, a mobile phone, a computer such as e.g. a laptop, a Personal Digital Assistants PDAs or a tablet computer, sometimes referred to as a surf plate, with wireless capability, or any other radio network units capable to communicate over a radio link in a wireless communications network. The term communication device used in this document also covers Machine to machine (M2M) devices. A service session 425 is provided to the communication device 430 by a service application running in the first service network node 421. The service session 425 may be represented by an application context.

In embodiments herein the first service network node 421 is also referred to as a source service network node. One or several of the one or more second service network nodes 422, 423, 424 may also be referred to as target or destination service network nodes. With this is meant that in embodiments herein a service session is to be migrated from the source service network node to a target or destination service network node. In embodiments herein target service network node and destination service network node have the same technical meaning.

In some embodiments the one or more second service network nodes 422, 423, 424 are associated with the second base station 412. This may be the case when the communication device 430 is to be handed over to a cell served by the second base station 412. The handover may for example be due to mobility of the communication device 430.

The handover may be performed between neighbor cells or between neighbor regions served by neighbor service network nodes 421 , 422, 423, 424, such as neighbor LCSs. In embodiments herein, a neighbor relationship between two service network nodes is a logical representation that means that there is a one hop logical distance between the two service network nodes. When the communication device 430 performs handover to a neighbor region, the service network node supporting that region serves the service session associated with the communication device 430. As a result, each neighbor service network node is a potential destination service network node for migration of the service session.

In some other embodiments the one or more second service network nodes 422,

423, 424 are associated with the first base station 41 1. This may be the case when session migration is needed due to a high load level in the first service network node 421.

In yet some further embodiments some of the one or more second service network nodes 422, 423, 424 are associated with the second base station 412 and some other of the one or more second service network nodes 422, 423, 424 are associated with the first base station 411.

Actions for requesting migration of a service session 425, i.e. for requesting session migration, to a second service network node 422, 423, 424 in the wireless communications network 400, will now be described in more detail in relation to Figure 5, Figure 6 and Figure 7.

The actions may be combined

Figure 5 is a combined flowchart and signalling diagram and illustrates the interaction between the different nodes that take part in embodiments herein.

Figures 6a and 6b describe a method in the first service network node 421 for requesting migration of the service session 425, while Figure 7 describes a method in one of the one or more second service network nodes 422, 423, 424 for assisting the first service network node 421 in requesting migration of the service session 425 to the second service network node 422, 423, 424. The service session 425 is provided to the communication device 430 by a service application running in the first service network node 421. Figure 6a relates to some first embodiments comprising action 601 and action 608, while Figure 6b relates to further embodiments comprising further actions.

In Figure 6b, some possible combination of actions are illustrated by the arrows. For example, some further embodiment comprise actions 601 , 602, 607 and 608. Other further embodiment comprise actions 601 , 602, 606, 607 and 608. Yet other further embodiment comprise actions 601 , 602, 604, 605 and 608. Further combinations of actions will be apparent to the person skilled in the art when reading the description of the actions.

Similarly In Figure 7, some possible combination of actions are illustrated by the arrows. For example, some first embodiment comprise action 701. In some embodiments the indication in action 701 is equivalent to the response in action 703 and then those embodiments may comprise action 703 instead of action 701. Some embodiments comprises both action 701 and 703 as will be apparent from the following description.

Some further embodiments comprise actions 701 and 705. Some further embodiments comprise actions 702 and 703. Yet some other further embodiments comprise actions 701 , 702 and 703. Yet some other further embodiments comprise actions 702, 703, 704 and 705. Further combinations of actions will be apparent to the person skilled in the art when reading the description of the actions.

In embodiments herein the first service network node 421 , i.e. the source service network node, receives an indication from one of the second service network nodes 422, 423, 424, that the second service network node 422, 423, 424 is able to admit migration of the service session 425. The indication is received in advance, i.e. before a potential handover has been triggered, or in other words before the first service network node 421 has requested migration of the service session 425, or even before the first service network node 421 has determined to migrate the service session 425.

When there are several second service network nodes 422, 423, 424 the first service network node 421 may receive an indication from several of the second service network nodes 422, 423, 424. Each such indication indicate whether or not a second service network node 422, 423, 424 is able to admit migration of the service session 425. In this way the first service network node 421 may discover and decide in advance which one of the one or more second service network nodes 422, 423, 424 is better suited to move the application context of the service session 425 to. This decision may be based on indications of available resources in the second service network nodes 422, 423, 424 or based on a response to a proactive request for admission control, i.e. a proactive AC request.

This reduces the probability of failure of AC of the session migration in the second service network node 422, 423, 424, i.e. in the target service network node, in conjunction with the actual handover and the session migration.

The proactive request for admission control may be sent to all possible neighbor service network nodes or to selected service network nodes. Such selection may e.g. be based on a mobility pattern of the communication device 430 and/or prediction of handover of the communication device 430.

Furthermore, the requests for admission control may be triggered by a soon to be expected or imminent handover of the communication device 430.

In some embodiments the requests for admission control is performed as soon as the communication device 430 activates an service session in the source service network node 421. The requests for admission control may even be performed regularly without association with a certain communication device. The first service network node 421 may keep the responses from such proactive admission controls and use them to select the next target service network node at the time of handover of the communication device 430.

Further, some embodiments herein include an option that a second service network node 422, 423, 424, i.e. a potential destination/target service network node, locally prepares for a potential coming session migration.

Such local preparations may e.g. comprise loading application code and/or configuration data from a slow memory 1691 to a fast memory 1692 comprised in the second service network node 422, 423, 424 as depicted in Figure 16. In this way the second service network node 422, 423, 424 is able to start executing the application faster after a coming session migration. For example, if a proactive admission control is successful at a potential destination service network node, this service network node may 5 prepare itself so as to be able to quicker accommodate and start executing the service session of the communication device 430 if the service session is subsequently transferred to the potential destination service network node.

In this way, the probability of AC failure at handover is further reduced.

The preparation of the target service network node may also reduce the application

10 execution interruption experienced for the communication device 430 in conjunction with session migration. When the session migration is combined with preparations at the target service network node, it is preferred that the source service network node 421 uses realtime information or close to real-time information from other service network nodes to make a decision regarding which potential target service network node to select for the

15 session migration. Therefore, this option is more suited when a proactive AC request is triggered by an indication that a handover with service session migration may be imminent. It is less suitable to be used in conjunction with periodic AC requests or AC requests which are performed without any indication of a soon-to-be-performed handover and/or session migration. The latter may be the case e.g. if proactive AC requests are

20 sent to neighbor service network nodes 422, 423, 424 as soon as an service session associated with the communication device 430 is started in or transferred to the source service network node 421.

One advantage of periodic AC requests is that the first service network node 421 has a recent information about the admission control of the second service network nodes

25 422, 423, 424 also when no event has triggered a proactive AC request recently.

Decisions about session migration may be quicker in this case than without the periodic AC requests.

There may be more than one service network node that potentially is able to support 30 an service session of the communication device 430 in a certain region. This may be e.g. a service network node at a base station site and one or more service network nodes on higher hierarchical level(s), e.g. a service network node at a hub site and a central service network node. The central service network node may e.g. be located above the (S)Gi interface. A plausible scenario is that if the proactive AC fails at a second service network node 422, 423, 424 at the lowest hierarchical level, then the source service network node 421 will instead choose to migrate the service session to a higher hierarchical service network node, such as a service network node at a hub site, covering the

5 cell/site/node/location the communication device 430 will be handed over to.

Actions 501 , 601 , 701

The first service network node 421 receives from one or more second service network nodes 422, 423, 424 a respective indication of whether or not the second service 10 network nodes 422, 423, 424 is able to admit migration of the service session 425.

The indication of whether or not the second service network 422, 423, 424 is able to admit migration of the service session 425 may comprise one or more of:

a resource availability level of the second service network node 422, 423, 424; a load level of the second service network node 422, 423, 424; and

15 a response to a request for admission control of migration of the service session 425, which response comprises an acceptance or a rejection of migration of the service session 425.

As a minimum the first service network node 421 receives from one of the second 20 service networks 422, 423, 424 an indication that the second service network node 422, 423, 424 is able to admit migration of the service session 425.

Similar to above the indication that the second service network node 422, 423, 424 is able to admit migration of the service session 425 may comprise one or more of:

the resource availability level of the second service network node 422, 423, 424; 25 the load level of the second service network node 422, 423, 424; and

the response to the request for admission control of migration of the service session 425, which response comprises the acceptance of migration of the service session 425.

The first service network node 421 may further receive from a further second 30 service network node 422, 423, 424, an indication of whether or not the further second service network node 422, 423, 424 is able to admit migration of the service session 425.

The indication of whether or not the further second service network 422, 423, 424 is able to admit migration of the service session 425 may comprise one or more of:

a resource availability level of the further second service network node 422, 423,

35 424; a load level of the further second service network node 422, 423, 424; and a response to a request for admission control of migration of the service session

425, which response comprises an acceptance or a rejection of migration of the service session 425.

Such further indications are received and described in action 502 below.

Each indication mentioned above may be transmitted and received via any of the following protocols: Media Independent Handover (MIH) protocol, Routing Information

Protocol (RIP) protocol, and Open Shortest Path First Traffic Engineering (OSPF-TE) protocol. In fact any information transfer approach, e.g. distance vectors algorithms, such as the RIP protocol, or an extension to link state algorithms, such as OSPF-TE, may be used to transfer the indications.

More specifically, the indication that the second service network node 422, 423, 424 is able to admit migration of the service session 425 may be transmitted and received via the MIH protocol, e.g. as part of an acceptance control request response or with the RIP protocol or OSPF-TE protocol. When using RIP or OSPF-TE a Routing Update Message may be used.

The indication of whether or not the further second service network node 422, 423, 424 is able to admit migration of the service session 425 may also be transmitted and received with the MIH protocol, e.g. as part of an acceptance control request response or with the RIP protocol or OSPF-TE protocol.

In some embodiments the reception of an indication of whether or not the second service network node (422, 423, 424) is able to admit migration of the service session (425) comprises receiving a Routing Update Message via any of:

- a Routing Information Protocol, RIP, and

- an Open Shortest Path First Traffic Engineering, OSPF-TE, protocol. In these embodiments the indication may comprise any of:

- a resource availability level of the second service network node (422, 423, 424), and

- a load level of the second service network node (422, 423, 424).

In some other embodiments the indication of whether or not the second service network (422, 423, 424) is able to admit migration of the service session (425) comprises a response to a request for admission control of migration of the service session (425). The response may comprise an acceptance or a rejection of migration of the service session (425). In these embodiments the response may be received via a Media

Independent Handover, MIH, protocol.

From the perspective of the one or more second service network nodes 422, 423, 5 424, they each sends to the first service network node 421 an indication of whether or not the second service network node 422, 423, 424 is able to admit migration of the service session 425. The indication is sent without having received from the first service network node 421 a prior request to migrate the service session 425.

In particular, each second service network node 422, 423, 424 may send an 10 indication that the second service network node 422, 423, 424 is able to admit migration of the service session 425.

Since the first service network node 421 receives from the second service network node 422, 423, 424 an indication that the second service network node 422, 423, 424 is able to admit migration of the service session 425, and since the first service network 15 node 421 requests migration of the service session 425 to the second service network based on the received indication the probability of failure of acceptance control at the time of handover is reduced.

Correspondingly, the first service network node 421 receives the indication that the second service network node 422, 423, 424 is able to admit migration of the service 20 session 425 before the first service network node 421 has requested migration of the service session 425 to the second service network node 422, 423, 424. I.e. without having sent a prior request for migration of the service session 425 to the second service network node 422, 423, 424.

In some embodiments the first service network node 421 receives the indication that 25 the second service network node 422, 423, 424 is able to admit migration of the service session 425 before it has requested migration the service session 425.

Since the first service network node 421 receives the indication that the second service network node 422, 423, 424 is able to admit migration of the service session 425 and requests migration of the service session 425 to the second service network node 30 422, 423, 424 based on the received indication, the probability of failure of admission control of the session migration in the second service network node 422, 423, 424, in conjunction with the actual handover and the session migration is reduced. The above scenario of receiving the indication and basing the request for migration on the indication may happen when the first service network node 421 receives the indication before it has 35 requested migration of the service session 425. In some embodiments, in which the first service network node 421 sends proactive preliminary requests for admission control to the one or more second service network nodes 422, 423, 424, the first service network node 421 receives a respective response to the respective request for admission control. The respective response comprises a respective indication of whether or not the respective one or more second service network node 422, 423, 424 is able to admit migration of the service session 425. This is related to actions 504, 604, 702 and 505, 605, 703 below.

Once a decision has been taken to migrate the service session 425, the indication or indications will be used to request migration of the service session 425 to a specific second service network node 422, 423, 424, i.e. to the target second service network node. As indicated below in actions 508, 607 the first service network node 421 may perform a selection process, based on the received indication or indications, to select the target service network node among the second service network nodes 422, 423, 424. Actions 502, 602

As mentioned already above in action 501 , in some embodiments the first service network node 421 receives from the further second service network node 422, 423, 424 a further indication. The further indication is an indication of whether or not the further second service network node 422, 423, 424 is able to admit migration of the service session 425.

Actions 503, 603

In some embodiments the first service network node 421 requests preliminary admission control of the session migration from the one or more second service network nodes 422, 423, 424. Preliminary means that the request for admission control is sent before the request for migration has been sent, i.e. without having sent a prior request for admission control of migration of the service session 425. The response to such a request for admission control indicates to the first service network node 421 whether or not the respective one or more second service network node 422, 423, 424 is able to admit migration of the service session 425. This reduces the probability of failure of admission control of the session migration in the second service network node 422, 423, 424, i.e. in the target service network node, in conjunction with the actual handover and the session migration.

It may be advantageous if the first service network node 421 does not send such preliminary requests to all of its neighbor service networks. Therefore, the first service network node 421 may select a respective second service network node 422, 423, 424 out of the one or more second service network nodes 422, 423, 424 for sending the respective request for admission control to the respective selected second service network node 422, 423, 424.

The selecting may be based on one or more of:

a mobility pattern of the communication device 430;

an indication that the communication device 430 is close to handover between the first radio access node 41 1 served by the first service network node 421 and the second radio access node 412 adapted to be served by the one or more second service network nodes 422, 423, 424;

the respective indication of whether or not the respective one or more second service network nodes 422, 423, 424 is able to admit migration of the service session 425; and

a load level of the first service network node 421 being above a threshold.

A mobility pattern may refer to a predictable pattern of physical movement of the communication device 430. For example, the communication device 430 is carried by a person travelling on a train. The communication device 430 which is connected to the wireless communications network 400 may exhibit a predictable mobility pattern in terms of the direction that it is headed towards.

Actions 504, 604, 702

As explained above in action 502 in some embodiments the first service network node 421 proactively requests potential target service network nodes for Admission Control in advance since this reduces the probability of failure of the AC of the session migration in the second service network node 422, 423, 424, in conjunction with the actual handover and the session migration.

The first service network node 421 may send a respective request for admission control of migration of the service session 425 to one or more second service network nodes 422, 423, 424.

The sending of the respective request for admission control to the respective one or more second service network nodes 422, 423, 424 may be triggered by one or more of:

a mobility pattern of the communication device 430;

an indication that the communication device 430 is close to handover between a first radio access node 41 1 served by the first service network node 421 and a second radio access node 412 adapted to be served by the one or more second service network nodes 422, 423, 424; and

a load level of the first service network node 421 being above a threshold.

If the first service network node 421 has selected second service network nodes for this purpose as described above in action 503, 603, the first service network node 421 may send the respective request for admission control to the respective selected second service network node 422, 423, 424.

Correspondingly, the second service network node 422, 423, 424 may receive the request for admission control of migration of the service session 425 from the first service network node 421.

The proactive request for admission control may optionally comprise various information about the communication device 430 and/or the user of the communication device 430. This information may facilitate well-founded AC at the second service network nodes 422, 423, 424. Such information may e.g. be one or more of:

which application(s) the communication device 430 is running,

the capabilities of the communication device 430,

policy information associated with the communication device 430 and/or user of the communication device 430, and

which applications the user of the communication device 430 subscribes to.

Actions 505, 605, 703

When the first service network node 421 has sent requests for admission control, the first service network node 421 receives a respective response to the respective request for admission control. The respective response comprises a respective indication of whether or not the respective one or more second service network node 422, 423, 424 is able to admit migration of the service session 425. In this case the indication is an acceptance or a rejection of migration of the service session 425.

Optionally, more nuanced responses may be introduced. Such details are provided further below.

Correspondingly, the second service network node 422, 423, 424 may send the indication to the first service network node 421 in a response to the received request for admission control of migration of the service session 425.

Actions 506, 704 In some embodiments the second service network node 422, 423, 424 prepares for migration of the service session 425 if the response to the request for admission control comprises an acceptance of migration of the service session 425. The preparing for migration of the service session 425 may comprise loading code of the service application 5 and/or configuration data of the service application from the slow memory 1691 to the fast memory 1692.

Actions 507, 606

The first service network node 421 may determine to migrate the service session 10 425, e.g. in response to a handover command from the first base station 411.

Actions 508, 607

When there are more than one second service network node 422, 423, 424 the first service network node 421 may select, based on the received indications, one out of the 15 second service network nodes 422, 423, 424 for requesting migration of the service

session 425.

For example, if one of the second service network nodes 422, 423, 424 has indicated that it is able to admit migration of the service session 425, while the other second service network nodes 422, 423, 424 have indicated that they are not able to 20 admit migration of the service session 425, then the first service network node 421

selects, based on the received indications, the second service network node 422, 423, 424 that it is able to admit migration of the service session 425.

Actions 509, 608, 705

25 The first service network node 421 requests migration of the service session 425 to the second service network node 422, 423, 424 based on the received indication. That is, the first service network node 421 requests migration of the service session to the second service network node 422, 423, 424 that has indicated that it is able to admit migration of the service session. The request is based at least on that indication. The request may

30 further be based on further indications from further second service network nodes 422, 423, 424.

Further details of embodiments

35 Embodiments will now be described in further detail with reference to Figures 8-14. The methods for session migration and for proactive admission control defined herein may be divided into: 1) proactive admission control which is dependent on the communication device 430; and 2) proactive admission control which is independent of the communication device 430.

When embodiments are exemplified below the service network nodes 421 , 422, 423, 424 will be exemplified with LSCs, and the communication device 430 will be exemplified with a UE.

Proactive admission control dependent on a specific communication device The proactive admission control which is dependent on a specific communication device, such as the communication device 430, may also be referred to as a UE specific variant.

An important advantage of this variant in relation to the variant that is independent of the communication device, i.e. UE independent variant, is that it is more resource efficient in terms of control signaling resources.

Another advantage is that in the UE specific variant more specific information may be provided in the AC request, so that a more well-founded decision about admission may be made in the second service network node 422, 423, 424. E.g. the decision may take aspects which are dependent of the communication device 430 into account. Information relating to such aspects may then be comprised in the AC request. Such aspects may be: which applications the communication device 430 is currently running,

the capabilities of the communication device 430,

policy information associated with the communication device 430 or user of the communication device 430, and which applications the communication device 430 subscribes to.

Some embodiments of the proactive admission control dependent on a specific communication device will now be summarized below. · The proactive AC is performed per communication device.

The source service network node 421 conducts the AC request to the possible next service network node 422, 423, 424, i.e., per communication device.

Each possible next service network node 422, 423, 424 processes the AC request for that particular communication device, such as the communication device 430, and sends the response back to the source service network node 421. The source service network node 421 keeps the response and applies that information at the handover time to determine to which service network node to migrate the service session related to the communication device 430. The response may be kept e.g. in a database dedicated for temporary storage of 5 proactive AC responses.

Within this variant of the method two approaches may be used: 1) Proactive admission control over all neighbor service network nodes per communication device; 2) Proactive admission control over selected neighbor service network 10 nodes based on a predicted motion of a communication device.

Proactive admission control over aM neighbor service network nodes per communication device

In this approach, when the communication device 430 registers into the new region

15 1 then the service network nodes supporting that region, e.g. the source service network node 421 , sends proactive AC requests as described above for actions 504, 604, to all service network nodes that are registered as its neighbor. The neighbourhood information, i.e. the information about which service network nodes 421 , 422, 423, 424 that are registered as neighbors, may be predefined and may be supplied to the service network

20 nodes 421 , 422, 423, 424 at the time of their start up. Since the neighbourhood

information depends on the network topology, this information may be supplied from the network administrators. In some other embodiments the service network nodes 421 , 422, 423, 424 may dynamically discover their neighbors. The neighbor service network nodes 422, 423, 424 will process the proactive AC request and provide their respective response

25 to the source service network node 421 , as described above for actions 505, 703.

Figure 8 shows an example of UE specific proactive admission control over all neighbor LSCs, where the UE 430 register itself to the first service network node 421 , e.g. by starting an application for which there is a server in the first service network node 421. Then the first service network node 421 sends proactive AC requests to all its neighbor

30 service network nodes 422, 423, 423. The neighbors provide the responses back to first service network node 421.

The proactive AC request may optionally comprise various information about the communication device 430 and/or the user of the communication device 430. This information may facilitate well-founded AC at the neighbor service network nodes 422,

35 423, 424. Such information may e.g. be one or more of: which application(s) the communication device 430 is running, the capabilities of the communication device 430,

which applications the user of the communication device 430 subscribes to.

A neighbor service network node may "ACCEPT" or "REJECT" the proactive AC request. Optionally, more nuanced responses may be introduced. For instance, an ACCEPT message may comprise information about the resource margin to the threshold where the ACCEPT would be replaced by a REJECT.

Similarly, a REJECT response may comprise information about how much of the resources that would have to be freed for the communication device 430 to be accepted. These types of information provides the source service network node with implicit indications of the probability that the outcome (i.e. ACCEPT or REJECT) of the proactive AC will change at a subsequent actual session migration.

The nuanced information may also be very useful when the source service network node is involved with these procedures for more than one communication device in parallel. Consider that the source service network node 421 sends proactive AC requests to a neighbor service network node for two communication devices, i.e. two separate proactive AC requests - one for each communication device -, and receives ACCEPT responses for both of them. The source service network node 421 may then realize that these advance acceptances apply for one communication device at a time and that the neighbor service network node has not committed itself to accommodating both communication devices. In this situation the source service network node 421 may use information about the resource margin included in the ACCEPT responses. This allows the source service network node 421 to determine whether the resources available at the neighbor service network node are enough for both communication devices or just for one of them.

Another way to deal with parallel proactive AC requests is that the service network node receiving these requests in action 504, 702, i.e. the second service network node 422, 423, 424, takes into account the number of "pending requests" when it determines whether to accept or reject the request. For example, if there are more pending requests than the capacity of the second service network node 422, 423, 424 then it may reject any new incoming requests. A pending request is a proactive AC request which is not known to have been followed by a subsequent session migration yet.

The second service network node 422, 423, 424 may have an algorithm for determining the resources that reasonably may be expected to be needed to

5 accommodate the fraction of the "pending requests" that will be followed by session migrations to the second service network node 422, 423, 424. The second service network node 422, 423, 424 may have learnt or configured a probability value, which indicates the probability that a proactive AC request will be followed by a subsequent session migration to the second service network node 422, 423, 424.

10 Optionally, this probability value may be different for different neighbor service

network nodes, i.e. the applied probability value may depend on which neighbor service network node the proactive AC request was received from.

If the AC response from the potential destination second service network node 422, 15 423, 424 is "ACCEPT" then, the second service network node 422, 423, 424 may

optionally perform local preparations for accommodating the application context of the communication device 430 in the future as described above for actions 506, 704. That is, if the session migration is eventually actually performed to that second service network node 422, 423, 424.

20 Such local preparations may e.g. comprise loading application code and/or

configuration data from a slow memory to a fast memory in order to be able to start executing the application faster after a possible coming session migration.

After the preparation, the potential destination second service network node 422, 423, 424 may stay in standby mode for receiving the application context of the

25 communication device 430 in the future. I.e. The second service network node 422, 423, 424 may stay in standby for a potential service session migration.

The source service network node 421 stores the proactive AC responses within a database and utilizes that database at the actual time for session migration.

30 Table 1 shows an example of the content of the database at the source service network node 421. In this example two communication devices are served by the source service network node 421.

LSC 422 LSC 423 LSC 424 LSC N response response response response

Table 1. Database content at a source LSC comprising proactive AC responses from neighbor service network nodes for two communication devices.

The source service network node 421 may send proactive AC requests for each communication device periodically to keep its database up to date. Figure 9 shows a flowchart describing the approach when the first service network node 421 sends proactive AC requests periodically to all neighbor service network nodes per

communication device. In action 901 the communication device 430 enters the region associated with the first service network node 421. In action 902 the first service network node 421 sends a proactive AC request. In action 903 the first service network node 421 makes or modifies a table comprising responses to proactive AC requests from the first service network node 421. In action 904 the first service network node 421 sets a timer. In action 905 the first service network node 421 checks whether or not the timer has expired. At expiry of the timer the first service network node 421 sends proactive AC requests again.

An alternative for keeping the database at the source service network node up to date is that the neighbor service network nodes 422, 423, 424 may register a source service network node 421 which they update when their status have changed. This latter approach may be realized as a sort of "subscribe-notify" procedure. That is, the source service network node 421 requests proactive AC in a neighbor service network node 422, 423, 424 for a certain communication device 430 and also requests the neighbor service network node 422, 423, 424 to periodically repeat the same proactive AC and notify the source service network node 421 whenever the result of the proactive AC changes. When the concerned communication device 430 leaves the source service network node 421 , e.g. because it is handed over to another service network node or because it stops running the application provided by the source service network node 421 , the neighbor second service network node 422, 423, 424 is informed that no further proactive AC repetitions and notifications are needed for the concerned communication device 430.

The indication to stop the repeated proactive ACs may be implicit. For example, for a neighbor second service network node 422, 423, 424 to which the communication device 430 is handed over the fact that the application/service session is migrated to the neighbor second service network node 422, 423, 424 may be such an implicit indication.

Proactive admission control over selected neighbor service network nodes 5 based on a predicted motion of the communication device

The approach to perform proactive AC per communication device across all neighbor service network nodes may cause greater control signaling overhead than when only selected neighbor service network nodes are involved.

When the communication device 430 enters into a region associated with the first

10 service network node 421 , such as region 1 in Figure 10, the first service network node 421 may predict the next handover of the communication device 430. The following is related to actions 503, 603 above. The first service network node 421 may select a respective second service network node 422, 423, 424 out of the one or more second service network nodes 422, 423, 424 based on an indication that the communication

15 device 430 is close to handover between the first radio access node 41 1 , served by the first service network node 421 , and the second radio access node 412, adapted to be served by the one or more second service network nodes 422, 423, 424.

This handover may be predicted based on analyzing mobility characteristics of the communication device 430, i.e. based on a mobility pattern of the communication device

20 430. The result from handover prediction may determine a list of service network nodes that are the most likely to serve the service session associated with the communication device 430 in the future.

The motion - and thus handover - prediction may be based on information gathered within a single cell or information related to multiple cells. It may be based on information

25 gathered/created by the wireless communications network 400 and/or information

generated by the communication device 430 and retrieved from the communication device 430 by the wireless communications network 400. Furthermore, the motion prediction may be based on information specific for the communication device 430 and/or information which is generic for communication devices. The motion prediction may comprise

30 direction, speed, velocity, and/or prediction of the next cell of the communication device 430.

The wireless communications network 400 may gather motion data within a single cell using Doppler shift measurements, changes in the timing advance, angle of arrival (AoA) measurements or any other network based positioning method for positioning of the 35 communication device 430, e.g. based on triangulation. The wireless communications network 400 may also generate motion data related to multiple cells for the communication device 430 in connected state and transfer the motion data between base stations in conjunction with handovers. E.g. in LTE the UE History Information IE in the X2AP Handover Request message may be used for this purpose.

5 From the communication device 430 the wireless communications network 400 may retrieve motion data in the form of GPS coordinates, e.g. collected at different points in time to allow derivation of a motion direction and speed. The wireless communications network 400 may further retrieve motion data from the communication device 430 in the form of motion/speed estimations autonomously generated by the communication device

10 430, e.g. based on successive GPS measurements.

Input data related to multiple cells may be retrieved from the communication device 430 that has been configured to collect motion/cell data, e.g. specifically for this purpose. The communication device 430 may then deliver the collected data to the wireless communications network 400 on request or when connecting to a new cell or based on

15 some other configured trigger. The communication device 430 may perform such data collection across multiple cells which the communication device 430 traverses in connected state or in idle state, i.e. with handovers or cell re-selection between the cells.

Generic motion statistics of communication devices is of interest in locations or areas where the majority of the communication devices follow a similar motion pattern.

20 E.g. because a highway or a railroad passes through the location or areas. The wireless communications network 400, e.g. base stations or core network nodes like MMEs, may learn such generic motion patterns related to communication devices by observing the mobility pattern of multiple communication devices, i.e. gathering data related to multiple communication devices communication device 430.

25 Any suitable algorithm may be used for motion and handover prediction.

With this approach, the source service network node 421 sends a proactive AC request to the potential destination service network node 422, 423, 424, i.e. the ones derived by the handover prediction algorithm, as shown in Figure 10. The motion and/or handover prediction algorithm based on the mobility direction of the communication

30 device 430 will indicate that the next handover most likely will occur to the second service network node 422 or the further second service network node 424. As a result, the source service network node 421 sends proactive AC requests to second service network node 422 and/or the further second service network node 424. This is in contrast to where the source service network node 421 sends proactive AC requests to all neighbor service

35 network nodes 422, 423, 424. One option for how to realize the motion prediction is to use a simple and direct form of motion prediction in the form of an early handover trigger as indicated in Figure 5 where an indication of a possible handover is taken as input into action 503 of selecting a second service network 422, 423, 424. This means that the wireless communications network 400, e.g. the radio access node 41 1 , or an RNC, modifies the trigger conditions for measurement reports from the communication device 430 or adds trigger conditions to the ones regularly used for support of identifying situations where handover is needed. The purpose is to configure the wireless communications network 400, e.g. the radio access node 411 , to receive an indication that the communication device 430 is close to a handover situation, but not really there yet. Compared to the measurement report trigger conditions that may be used for identifying handover situations, these trigger conditions may e.g. have shorter time-to-trigger, lower thresholds, e.g. for the channel quality, such as Reference Signal Received Power (RSRP) or Reference Signal Received Quality (RSRQ), for neighboring cells, and/or higher thresholds, e.g. for the channel quality, such as RSRP or RSRQ, for a serving cell. Time-to-trigger is the time the trigger condition must persist before the communication device 430 sends a measurement report. The result of this will be that when the communication device 430 is on its way out of a cell and into a neighbor cell, the wireless communications network 400 will be informed of this imminent event slightly earlier.

When the wireless communications network 400, e.g. the radio access node 41 1 , receives this indication, e.g. in the form of a measurement report, it may decide to send a request for proactive AC to one or more of its neighbor service network nodes 422, 423, 424, which are topological^ located such that they may beneficially support the communication device 430 in its expected next cell.

Preferably, the communication device 430 may also be configured with

measurement report trigger conditions for the actual situation that would typically trigger a handover, i.e. the regular trigger conditions for handover supporting measurement reports. When the wireless communications network 400 receives a measurement report triggered by these typical trigger conditions, it uses its regular internal algorithms for deciding whether to handover the communication device 430 to the concerned target neighbor cell.

Another alternative may be that the wireless communications network 400 only relies on the earlier triggered measurement report and simply triggers the handover decision with a slight delay after receiving the measurement report. The proactive AC procedures may take place during this delay.

The potential target service network node 422, 423, 424 may "ACCEPT" or 5 "REJECT" the proactive AC request, e.g. indicate whether it has the available resources to serve the UE or not. Optionally the target service network node 422, 423, 424 may also provide additional information as described above.

If the AC response from the potential destination service network node 422, 423, 424, i.e. the "proactive AC response", is "ACCEPT", then the target service network node 10 422, 423, 424 may optionally perform local preparations for accommodating the

application context of the communication device 430 in the future when the session migration is eventually actually performed to that neighbor service network node 422, 423, 424. Such local preparations may e.g. comprise loading application code and/or configuration data from a slow memory to a fast memory in order to be able to start 15 executing the application faster after a possible coming session migration.

This approach, where the proactive AC is performed per communication device to predicted candidate target service network nodes 422, 423, 424 introduces less control signaling load than when AC request are sent to all neighbor service network nodes. The 20 response from each candidate second service network node 422, 423, 424 may be kept in a database at the source service network node 421 and may be used at the time of actual handover.

Table 2 shows an example content of such a database at the source service network node 421 in an example where one communication device 430 is served by the

25 source service network node 421.

LSC 421 LSC 422 LSC 423 LSC N response response response response

UE NA NO YES NA

Table 2. Database content at source service network node 421 comprising response from second service network nodes 422, 423, 424 predicted as likely for handover for the communication device 430. NA represents Not Applicable.

The communication device 430 may change its behavior in a way that the prediction of the future handover and candidate second service network nodes 422, 423, 424 changes. In this case, the source service network node 421 sends a proactive AC request to new candidate destination second service network node 422, 423, 424.

Optionally, the source service network node 421 may also send a release or cancellation indication to the previous candidate destination service network node 422, 423, 424 which are no longer candidates. This option is useful e.g. if a previous candidate destination service network node 422, 423, 424 has prepared for the arrival of the communication device 430 and thus to some extent reserved or occupied resources or adapted some configuration accordingly. The previous candidate service network nodes 422, 423, 424 may thus de-allocate resources reserved for the service session of the communication device 430 upon receiving an indication of release or cancellation. The prediction of potential next service network nodes 422, 423, 424 may be performed from time to time or consistently periodically repeated.

Figure 11 shows a flowchart describing actions corresponding to some

embodiments where the candidate destination service network nodes 422, 423, 424 are predicted based on mobility patterns of the communication device 430. Subsequently, e.g. periodically, the prediction is reassessed to catch possible deviations from the expected mobility pattern. Note that a possible timer for control of periodic prediction reassessment is not shown.

In action 1 101 the communication device 430, exemplified as a UE, enters into a region, such as region 1.

In action 1 102 the first service network node 421 predicts target service network node 422, 423, 424 candidates based on the mobility pattern of the communication device 430. In action 1 103 the first service network node 421 sends proactive AC requests to candidate target service network nodes 422, 423, 424. In action 1 104 the first service network node 421 makes or modifies a table that comprises information about candidate target service network nodes 422, 423, 424 and their responses to proactive AC requests. In action 1 105 the first service network node 421 reassess prediction of target service network node 422, 423, 424 candidates based on the mobility pattern of the

communication device 430. Action 1 105 is performed to catch changes in the mobility pattern. In action 1 106 the first service network node 421 checks if there is a change in the list. In action 1107 the first service network node 421 sends proactive AC requests to new neighbor second service network nodes 422, 423, 424 in the list of candidate destination service network nodes 422, 423, 424. In action 1 108 the first service network node 421 sends release/cancellation indications to previous candidate second service network node 422, 423, 424, which are not target candidate service network nodes 422, 423, 424 anymore.

In both mentioned approaches discussed above, when the communication device 5 430 switches to a new service network node, then a release/cancellation indication may be sent to other potential destination service network nodes, which have performed proactive AC, to de-allocate any reserved capacity for that particular communication device 430.

Figure 12 illustrates a possible behavior of the source service network node 4210 after handover 1201 of the communication device 430. In action 1202 the first service network node 421 sends a release request to previous neighbor second service network nodes 422, 423, 424 which are not neighbor service network nodes anymore after handover. In action 1203 the communication device 430 enters into the target region. 5 Proactive admission control independent of the communication device

Some characteristics of the independent proactive admission control approach may be described as:

• All neighbor second service network nodes 422, 423, 424 will send information about their resource status to the source service network node 421 as described0 above in actions 505, 703. To achieve this all service network nodes 421 , 422,

423, 424 keep all their respective neighbor service network nodes 421 , 422, 423, 424 updated with the resource status. The Routing Update Message may be used for this purpose using RIP or OSPF-TE protocols. Resources may be of two kinds. The first kind are physical resources, i.e. infrastructure resources, such as5 processing resources, memory disk space etc. The other kind are application resources such as the availability of an application itself and the contents that the application is serving. For example, if the application is a video server then content is the videos available with the application.

• The source service network node 421 keeps the status of its neighbors within a0 database. I.e., all service network node 421 , 422, 423, 424 do this for their

respective neighbor service network nodes.

• The source service network node 421 utilizes that database at handover time to determine where the service session of the communication device 430 may be migrated with a low probability of rejection, e.g. with lowest probability of rejection.5 A further obvious condition is that this target second service network node 422, 423, 424 must be able to serve the communication device 430 at the new location, e.g. its new cell and/or base station.

In this approach, service network nodes update their neighbors with information such as their resource status, i.e. the status related to resources to service the

communication device 430 with the service session 425, supported application, and available content. As a result, each service network node will have information about the latest status of its service network node neighbors.

Figure 13 illustrates an example where the service network nodes are exemplified with LSCs and the communication device 430 is exemplified with a UE 430. LSC 421 , which is serving a UE 430, receives updates from all its neighbors, i.e., LSC 422, LSC 423, LSC424, and LSC N. As discussed previously, the neighbors of one service network node comprise all service network nodes that are logically connected to it with one hop. In this case, LSC 421 may build a database comprising information about all its neighbors. Such information may correspond to the received indication of whether or not the second service network node 422, 423, 424 is able to admit migration of the service session 425. E.g. the information may comprise the resource availability level of the second service network node 422, 423, 424, the load level of the second service network node 422, 423, 424 and the response to the request for admission control of migration of the service session 425. As mentioned above, the response comprises an acceptance or a rejection of migration of the service session 425. Further and more detailed examples of the information in the database are given below.

Table 3 shows an example of the database content at LSC 421. To make an appropriate decision on where to migrate the service session of the UE 430 at handover time, the database of LSC 421 may reflect the real-time situation of the neighbor LSCs. To maintain the database, the neighbor LSCs may send status updates periodically or send an update when any change occurred in their state.

In case the updates are triggered by significant changes, this may involve "binary" changes or "on/off" changes, such as e.g., new content available. Significant changes may also involve quantitative types of changes, such as significant changes in the available resources.

In some cases, e.g. when it comes to resource allocation and/or availability status a "change" that triggers an update to be sent may be subject to a, preferably configurable, threshold. This is in order to allow tuning of a trade-off between update frequency and accuracy and/or granularity of the information.

Yet another option may be that an update is triggered only when there is a shortage of resources or when the resource situation changes from "enough available resources to accommodate a communication device" to "too little resources available to accommodate the communication device " or vice versa. Even though periodic updates between all neighbor service network nodes cause signaling overhead, this overhead does not scale or grow with the number of communication devices.

Any information transfer approach, e.g. distance vectors algorithms such as the Routing Information Protocol (RIP) protocol, or an extension to link state algorithms such as Open Shortest Path First Traffic Engineering (OSPF-TE) may be modified to provide real-time or close to real-time information. This is also related to e.g. actions 501 and 502 described before.

Neighbors Resource status List of application List of available content

LSC 422 [CPU, RAM, BW, . ^■ ] [App1 , App2,...] [Content"! , Content2,...]

LSC 423 [CPU, RAM, BW, . ^■ ] [App2, App3, App4,...] [Content"! , Content2,...]

LSC 424 [CPU, RAM, BW, . ^■ ] [App1 , App3,...] [Content"! , Content2,...]

LSC_N [CPU, RAM, BW, . ^■ ] [App1 , App2, App3,...] [Content"! , Content2,...] Table 3. An example of database content at LSC 421 containing information about its neighbor LSCs. The available content may be a video file, if the application is a video streaming service. The available content may be a text content if the application is a web service. The content thus depends on the application. At the time of handover of a UE, or when getting close to the time of handover, the source LSC uses the content of its database to serve as basis for proactive admission control, such that the source LSC determines based on the database content whether a desired target LSC is able to serve the service session(s) of the UE to be handed over. In a sense, the source LSC performs the proactive admission control on behalf of its neighbor LSC, based on the database content. This is related to the selecting action 508 above.

Alternatively, the source LSC does not fully rely on the database content when a handover with service session migration is about to take place. This may e.g. be in cases where the resource availability at the concerned neighbor LSC is not abundant and makes it uncertain whether the UE's service session(s) will be accepted. In this situation the source LSC may request the concerned neighbor LSC for proactive admission control. Proactive AC was described above in relation to action 505. In this case the proactive AC may be executed after action 507, determining to migrate the service session, but before the action 508 of requesting migration of the service session.

Another option may be that the source LSC only uses the database content for a rough ranking of the potential target LSCs and then always requests the high-ranked potential target LSCs for proactive admission control before a session migration. With these schemes two methods may be used for proactive admission control: 1) Proactive admission control on all the neighboring LSCs; 2) Proactive admission control over potential LSCs based on the predicted motion of the UE.

Optionally, If the source LSC, judging from its database, recognizes that a UE needs particular applications or contents that are not available at a certain neighbor LSC or at any neighbor LSC, it may ask the neighbor to proactively launch that application. E.g. it may ask the neighbor LSC to move the application code from a slow memory to a fast memory, or retrieve the application code from a remote location, or retrieve that content e.g. from a central or Internet based server, in order to be able to serve the UE in case of a handover. If the neighbor LSC is able to do that, it informs the source LSC at the next resource status update. The next resource status update may be immediately if the update is triggered by changes.

Optionally, the request for such proactive actions may not be sent to a neighbor LSC, if the probability that the neighbor LSC will be able to serve the UE is low. The source LSC may judge that from the indicated resource situation of the neighbor LSC. UE independent proactive admission control over all the neighboring LSCs

Some embodiments will now be illustrated with the flowchart of Figure 14. In these embodiments, as described above, at handover time, action 1401 , the source LSC looks into its neighbor database that comprises the latest information about its neighbors' status. By analyzing 1402 the neighbor database the source LSC identifies 1403 an appropriate LSC to migrate the service session. Such appropriate neighbor LSC may be an LSC with low probability of rejecting the AC and which is able to serve the UE at the expected new UE location.

If the source LSC does not find any suitable neighbor LSC in the current hierarchical level that is able to admit the session migration, then the source LSC tries to find an LSC in any of the other higher hierarchies. Failure to find any LSC after such actions may result in the source LSC dropping the session in action 1404.

As a result, if the primary target LSC cannot support the UE session, e.g., due to lack of resources or other reasons such as application not supported on that LSC platform, then the source LSC may identify that before the actual AC is performed in conjunction with the handover.

The source LSC sends 1405 a request for AC together with the request for migration to the identified neighbor LSC. If the request for AC is accepted the source LSC continues 1407 with the session migration.

If the request is rejected the source LSC modifies 1408 the database comprising information about the neighbor LSCs. The modified database comprises information that the identified neighbor LSC does support migration of the service session.

In other words, the source LSC predicts the response of actual admission control by analyzing information stored in its neighbor database. As a result, the source LSC may ignore the primary option, if the source LSC assesses that the primary option LSC may not support the UE session, and try another alternative, e.g. an LSC at a higher hierarchical level.

The probability of failure at AC will be reduced with this method. This source LSC behavior contrasts to the regular session migration method where the source LSC sends an AC request to an intended target LSC and if the target LSC rejects the request, the source LSC tries a second alternative destination LSC and so on.

Also the above described alternative where the source LSC does not fully rely on the neighbor database may be used also with these embodiments. I.e. when a handover is approaching for a UE the source LSC may send proactive AC requests to selected neighbor LSC(s), where this selection of neighbor LSC(s) is based on the content of the neighbor database.

UE independent proactive admission control over potential destination LSCs based on the predicted motion of the UE

UE motion prediction or mobility prediction may be useful also in the conjunction with the alternative embodiments using UE independent proactive admission control.

The source LSC may then select the neighbor LSC(s) in its neighbor database, which may serve the UE's predicted next location and which have any other capabilities that are needed to serve the UE's service session(s). Hence, the proactive admission control may still be UE independent, but the database created by the UE independent proactive admission control may be utilized in a UE specific manner.

The motion/mobility prediction may be performed using the same methods as described above and may be based on either UE specific motion data or generic UE mobility pattern or both.

To perform the method actions of for requesting migration of a service session 425 in the wireless communications network 400 described above in relation to Figures 5 and 6, the first service network node 421 may comprise the following arrangement depicted in Figure 15.

As mentioned above, the first service network node 421 comprises the service application configured to provide the service session to the communication device 430.

The service session 425 is configured to be associated with the communication device 430 in the wireless communications network 400. The service session 425 is configured to be provided to the communication device 430 by the service application configured to run in the first service network node 421.

The first service network node 421 is configured to, e.g. by means of a receiving module 1510 configured to receive from the second service network node 422, 423, 424 an indication that the second service network node 422, 423, 424 is able to admit migration of the service session 425.

The first service network node 421 may be configured to receive the indication that the second service network node 422, 423, 424 is able to admit migration of the service session 425 before the first service network node 421 has requested migration of the service session 425.

The receiving module 1510 may be implemented, at least in part, by a processor 1580 in the first network node 421. The first service network node 421 is further configured to, e.g. by means of a requesting module 1520 configured to, request migration of the service session to the second service network node 422, 423, 424 based on the received indication.

The first service network node 421 may be further configured to, e.g. by means of the MIHF module 511 configured to, detect the handover command, which handover command commands handover of the communication device 430 from the first base station 41 1 to the second base station 412.

In some embodiments the first service network node 421 is further configured to, 5 e.g. by means of the receiving module 1510 configured to, receive from a further second service network node 422, 423, 424 an indication of whether or not the further second service network node 422, 423, 424 is able to admit migration of the service session 425, and further configured to, e.g. by means of a selecting module 1530 configured to, select based on the received indications one out of the second service network nodes 422, 423, 10 424 for requesting migration of the service session 425.

The first service network node 421 may be further configured to, e.g. by means of a sending module 1540 configured to, send a respective request for admission control of migration of the service session 425 to one or more second service network nodes 422, 15 423, 424.

Then the first service network node 421 is also further configured to, e.g. by means of the receiving module 1510 configured to, receive a respective response to the respective request for admission control, which respective response comprises a respective indication of whether or not the respective one or more second service network

20 node 422, 423, 424 is able to admit migration of the service session 425, and wherein the indication is an acceptance or a rejection of migration of the service session 425.

The first service network node 421 may be configured to send the respective request for admission control to the respective one or more second service network nodes 422, 423, 424 when triggered by one or more of:

25 a mobility pattern of the communication device 430;

an indication that the communication device 430 is close to handover between a first radio access node 411 served by the first service network node 421 and a second radio access node 412 adapted to be served by the one or more second service network nodes 422, 423, 424; and

30 a load level of the first service network node 421 being above a threshold.

The first service network node 421 may be configured to select a respective second service network node 422, 423, 424 out of the one or more second service network nodes 422, 423, 424, and send the respective request for admission control to the respective selected second service network node 422, 423, 424. Then the first service network node

35 421 is further configured to base the selection on one or more of: a mobility pattern of the communication device 430;

an indication that the communication device 430 is close to handover between the first radio access node 411 served by the first service network node 421 and the second radio access node 412 adapted to be served by the one or more second service network nodes 422, 423, 424;

a load level of the first service network node 421 being above a threshold.

The embodiments herein for handling the service session associated with the communication device 430 in the wireless communications network 400, may be implemented through one or more processors, such as the processor 1580 in the first service network node 421 depicted in Figure 15, together with computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the

embodiments herein when being loaded into the first service network node 421. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the first service network node 421.

The first service network node 421 may further comprise a memory 1590

comprising one or more memory units. One memory unit 1591 may be a slow memory unit, while another memory unit 1592 may be a fast memory unit. The memory 1590 is configured to store e.g. the indications of admissibility of the communication device 430, such as acceptance or rejection of AC requests and/or indications of load level and or available resources in the second service network nodes 422, 423, 424, and computer program code to perform the methods herein when being executed in the first service network node 421.

Those skilled in the art will also appreciate that the modules described above may refer to a combination of analogue and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in a memory, that when executed by the one or more processors such as the processor 1580 perform as described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether 5 individually packaged or assembled into a System-on-a-Chip (SoC).

To perform the method actions for assisting the first service network node 421 in requesting migration of the service session 425 in the wireless communications network 400, described above in relation to Figures 5 and 7, the second service network node 10 422, 423, 424 may comprises the following arrangement depicted in Figure 16.

The second service network node 422, 423, 424 is configured to, e.g. by means of a sending module 1610 configured to, send to the first service network node 421 an indication of whether or not the second service network node 422, 423, 424 is able to 15 admit migration of the service session 425. The indication is sent without having received from the first service network node 421 a prior request to migrate the service session 425.

The sending module 1610 may be at least partly implemented by a processor 1680 in the second service network node 422, 423, 424.

20 The second service network node 422, 423, 424 may be configured to, e.g. by

means of a receiving module 1620 configured to, receive a request for admission control of migration of the service session 425 from the first service network node 421 , and further configured to, e.g. by means of the sending module 1610 configured to, send the indication to the first service network node 421 in a response to the received request for

25 admission control of migration of the service session 425. Then the indication is an

acceptance or a rejection of migration of the service session 425.

The receiving module 1620 may be at least partly implemented by the processor 1680 in the second service network node 422, 423, 424.

30 In some embodiments the second service network node 422, 423, 424 is configured to, e.g. by means of a preparation module 1630 configured to, prepare for migration of the service session 425 if the response comprises an acceptance of migration of the service session 425. The second service network node 422, 423, 424 may be configured to prepare for migration of the service session 425 by loading code of the service application and/or configuration data of the service application from a slow memory to a fast memory.

The preparation module 1630 may be implemented by the processor 1680 in the second service network node 422, 423, 424.

The embodiments herein for assisting the first service network node 421 in requesting migration of the service session 425 in the wireless communications network 400 may be implemented through one or more processors, such as the processor 1680 in the second service network node 422, 423, 424 depicted in Figure 16, together with computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the second service network node 422, 423, 424. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the second service network node 422, 423, 424. The second service network node 422, 423, 424 may further comprise a memory 1690 comprising one or more memory units. One memory unit 1691 may be a slow memory unit, while another memory unit 1692 may be a fast memory unit. The memory 1690 is arranged to store for example application code and/or configuration data related to the service session 425.

The memory 1690 may further be arranged to store configurations, and computer program code to perform the methods herein when being executed in the second service network node 422, 423, 424.

The first and second service network nodes 421 , 422, 423, 424 may each comprise the following modules for the migration of a service session: a Media Independent Handover function (MIHF) module 1511, 1611 , an application and network connection Migration System (MS) module 1512, 1612 and a Session Mobility Interface module 1513, 1613. The following sections describe the three modules in detail. The interfacing of each module will be described in detail later. The ecosystem may also comprise a 3G-LTE/SAE network and service applications whose service sessions need migration as the user equipment, e.g. the communication device 430, is handed over from one base station to another, e.g. from the first base station 411 to the second base station 412. The first and the second service network nodes 421 , 422, 423, 424 may be used to migrate service sessions from one base state to another, e.g. from the first base station 41 1 to the second base station 412.

Media Independent Handover Function (MIHF) module 1511, 1611

MIH is an IEEE 802.21 specification that enables handovers between

heterogeneous networks without service disruption. MIH provides a framework for lower layer handover signals and/or indications from the 3G-LTE/SAE network to be relayed to higher layers in a technology agnostic manner. In embodiments herein the MIHF module is configured to provide handover enabling signals, also referred to as triggers, to the higher layers in order to achieve a seamless handover of the application states and the network connection sessions related to the service session.

MS module 1512, 1612

The MS module 1512, 1612 may be responsible for the migration of the service session associated with the communication device 430 from one base station to another in the event of a user equipment handover in the wireless communications network 400. The MS module 1512, 1612 is responsible for migration of an application state associated with the services session and a network connection state, each associated with the service session and each being specific for the communication device 430.

Application states of the service session are snapshots of the current execution sequence of the service that may be paused and then restarted on another instance of the service, e.g. in a corresponding service application in another service network node, such as the second service network node 422, 423, 424.

Network connection migration, i.e. migration of the network connection states, involves transfer of protocol states, e.g. TCP connection states, associated with the connection between the service session and the communication device 430. Network connection migration also involves the data in transit between the service application and the communication device 430.

SMI module 1513, 1613

The SMI module 1513, 1613 integrates the MIHF module 1511 , 1611 and the MS module 1512, 1612 together. The SMI module 1513, 1613 also provides the service application with a simple and clear interface to migrate the service session associated with the communication device 430 from one service application instance to another, i.e. from the service application running in the first service network node 421 to a

corresponding service application running in the second service network node 422, 423, 5 424. The SMI module 1513, 1613 also provides a standard interface over which the information about the application states and network connection states may be transferred. Context Transfer Protocol (CXTP) may be used to exchange the state information between two SMI modules. 0 Those skilled in the art will also appreciate that the MIHF module 151 1 , 1611 the MS module 1512, 1612 and the SMI module 1513, 1613 described above may refer to a combination of analogue and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in a memory, that when executed by the one or more processors such as the processor 1580, 1680 perform as described above. One or5 more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a System-on-a-Chip (SoC). 0 Interfaces

Possible interfaces between the different modules comprised in the service network nodes, and possible interfaces between the modules comprised in the service network nodes and other entities interacting with the service network nodes will now be described. These interfaces are depicted in Figure 17.

5

Interface 81

This interface is used by the SMI module 1513, 1613 to inform the service application to prepare for migration of its session states. The service application uses this interface to export and import the session states to and from the SMI module 1513, 1613.0 Primitives, also referred to as APIs, of this interface are given below:

- PREPARE_TO_EXPORT (uejdentifier).

- EXPORT(ue_identifier, session_data)

- PREPARE_TO_IMPORT (uejdentifier)

5 - IMPORT(ue_identifier, session_data) Interface 82

This is a standard interface between the MIHF module 151 1 , 1611 and its user, in this case the SMI module 1513, 1613. The interface is defined by the IEEE 802.21 5 specification. Primitives of this interface are the Ml H commands and events as defined in the IEEE 802.21 specification.

Interface 83

This interface is used by the SMI module 1513 to request the first MS module 1512 10 to extract the service session information that is UE specific and the network connection states associated with the service session in case of an export operation. In case of an import operation the second SMI module 1613 requests the second MS module 1612 to induct a new UE specific session into the service application and to import, or extract, the network connections associated with the session from the CXTP message. Primitives of 15 this interface are given below:

SESSION_EXPORT(ue_identifier, session_data)

SESSION_IMPORT(ue_identifier, session_data)

SESSION_EXPORTED (uejdentifier, session_data)

SESSIONJMPORTED (uejdentifier, session_data)

Interface 84

This is a standard interface between the MIHF module and the 3G-LTE/SAE subsystems. This interface is a technology agnostic abstraction as defined by the IEEE 25 802.21 specification. This interface is used to relay link layer events related to handover from the 3G-LTE/SAE subsystems to the first MIHF module 151 1. The primitives of this interface are link events and link commands defined by the IEEE 802.21 specification.

Interface 85

30 This interface is used by the first SMI module 1513 to transfer the application and protocol state information to its peer, i.e. the second SMI module 1613. This interface uses the CXTP protocol to transfer the session state related information.

Interface 86 This is a standard interface between local and remote MIHF modules, such as the first MIHF module 151 1 and the second MIHF module 1611. This interface is used by the MIHF modules to coordinate and achieve a handover. The primitives for this interface are the remote MIH commands and events as defined by the IEEE 802.21 specification.

Note that terminology such as a first service network node and a second service network node should be considered to be non-limiting and does in particular not imply a certain hierarchical relation between the two. When using the word "comprise" or "comprising" it shall be interpreted as non- limiting, i.e. meaning "consist at least of".

The embodiments herein are not limited to the above described preferred embodiments. Various alternatives, modifications and equivalents may be used. In other words, although terminology from 3GPP LTE/SAE has been used to exemplify embodiments herein, this should not be seen as limiting the scope of the embodiments herein to only the aforementioned system. Other wireless systems using Layer-3 and above connection handover mechanisms, including UMTS, GSM, any 3GPP cellular network and other, may also benefit from exploiting the ideas underlying the

embodiments.

Therefore, the above embodiments should not be taken as limiting the scope, which is defined by the appending claims.

Claims

A method in a first service network node (421) for requesting migration of a service session (425) to a second service network node (422, 423, 424), wherein the service session (425) is associated with a communication device (430) in a wireless communications network (400), and wherein the service session (425) is provided to the communication device (430) by a service application running in the first service network node (421), the method comprising:

receiving (501 , 505, 601 , 605), from the second service network node (422, 423, 424), an indication that the second service network node (422, 423, 424) is able to admit migration of the service session (425); and

requesting (509, 608) migration of the service session (425) to the second service network node (422, 423, 424) based on the received indication.

The method according to claim 1 , wherein the indication that the second service network node (422, 423, 424) is able to admit migration of the service session (425) comprises one or more of:

a resource availability level of the second service network node (422, 423, 424);

a load level of the second service network node (422, 423, 424); and a response to a request for admission control of migration of the service session (425), which response comprises an acceptance or a rejection of migration of the service session (425), and which response is received via a Media Independent Handover, MIH, protocol.

The method according to any of the claims 1-2, further comprising:

receiving (501 , 505, 602, 605) from a further second service network node (422,

423, 424), an indication of whether or not the further second service network node

(422, 423, 424) is able to admit migration of the service session (425); and

selecting (508, 607), based on the received indications one out of the second service network nodes (422, 423, 424) for requesting migration of the service session (425).

The method according to claim 3, wherein the indication of whether or not the further second service network (422, 423, 424) is able to admit migration of the service session (425) comprises one or more of:

a resource availability level of the further second service network node (422, 423, 424);

a load level of the further second service network node (422, 423, 424); and a response to a request for admission control of migration of the service session (425), which response comprises an acceptance or a rejection of migration of the service session (425), and which response is received via a Media Independent Handover, MIH, protocol.

The method according to any of the claims 1-4, wherein the reception of an indication of whether or not the second service network node (422, 423, 424) is able to admit migration of the service session (425) comprises receiving a Routing Update Message via any of:

- a Routing Information Protocol, RIP, and

- an Open Shortest Path First Traffic Engineering, OSPF-TE, protocol, and wherein the indication comprises any of:

- a load level of the second service network node (422, 423, 424).

The method according to any of the claims 1-5, further comprising:

sending (504, 604) a respective request for admission control of migration of the service session (425) to one or more second service network nodes (422, 423, 424); and

receiving (505, 605) a respective response to the respective request for admission control, which respective response comprises a respective indication of whether or not the respective one or more second service network node (422, 423, 424) is able to admit migration of the service session (425), and wherein the indication is an acceptance or a rejection of migration of the service session (425).

7. The method according to claim 6, wherein sending (504) the respective request for admission control to the respective one or more second service network nodes (422, 423, 424) is triggered by one or more of: a mobility pattern of the communication device (430);

an indication that the communication device (430) is close to handover between a first radio access node (41 1) served by the first service network node (421) and a second radio access node (412) adapted to be served by the one or more second service network nodes (422, 423, 424); and

a load level of the first service network node (421) being above a threshold.

The method according to any of the claims 6-7, further comprising:

selecting (503, 603) a respective second service network node (422, 423, 424) out of the one or more second service network nodes (422, 423, 424), and sending (504, 604) the respective request for admission control to the respective selected second service network node (422, 423, 424); and wherein the selecting (502) is based on one or more of:

a mobility pattern of the communication device (430);

an indication that the communication device (430) is close to handover between the first radio access node (41 1) served by the first service network node (421) and the second radio access node (412) adapted to be served by the one or more second service network nodes (422, 423, 424);

the respective indication of whether or not the respective one or more second service network nodes (422, 423, 424) is able to admit migration of the service session (425); and

a load level of the first service network node (421) being above a threshold.

The method according to any of the claims 1-8, wherein the receiving (501 , 505, 601 , 605) of the indication that the second service network node (422, 423, 424) is able to admit migration of the service session (425) is performed before the first service network node (421) has requested migration of the service session (425).

A first service network node (421) configured to request migration of a service session (425) to a second service network node (422, 423, 424), wherein the service session (425) is configured to be associated with a communication device (430) in a wireless communications network (400), and wherein the service session (425) is configured to be provided to the communication device (430) by a service application configured to run in the first service network node (421), and wherein the first service network node (421) is configured to: receive from the second service network node (422, 423, 424), an indication that the second service network node (422, 423, 424) is able to admit migration of the service session (425); and

request migration of the service session (425) to the second service network node (422, 423, 424) based on the received indication.

The first service network node (421) according to claim 10, wherein the indication that the second service network node (422, 423, 424) is able to admit migration of the service session (425) comprises one or more of:

a load level of the second service network node (422, 423, 424); and a response to a request for admission control of migration of the service session (425), which response comprises an acceptance or a rejection of migration of the service session (425).

The first service network node (421) according to any of the claims 10-1 1 , further configured to:

receive from a further second service network node (422, 423, 424) an indication of whether or not the further second service network node (422, 423, 424) is able to admit migration of the service session (425); and

The first service network node (421) according to claim 12, wherein the indication of whether or not the further second service network (422, 423, 424) is able to admit migration of the service session (425) comprises one or more of:

a load level of the further second service network node (422, 423, 424); and a response to a request for admission control of migration of the service session (425), which response comprises an acceptance or a rejection of migration of the service session (425). The first service network node (421) according to any of the claims 10-13, further configured to:

send a respective request for admission control of migration of the service session (425) to one or more second service network nodes (422, 423, 424); and receive a respective response to the respective request for admission control, which respective response comprises a respective indication of whether or not the respective one or more second service network node (422, 423, 424) is able to admit migration of the service session (425), and wherein the indication is an acceptance or a rejection of migration of the service session (425).

The first service network node (421) according to claim 14, wherein the first service network node (421) is configured to send the respective request for admission control to the respective one or more second service network nodes (422, 423, 424) when triggered by one or more of:

a mobility pattern of the communication device (430);

a load level of the first service network node (421) being above a threshold.

The first service network node (421) according to any of the claims 14-15, further configured to:

select a respective second service network node (422, 423, 424) out of the one or more second service network nodes (422, 423, 424), and

send the respective request for admission control to the respective selected second service network node (422, 423, 424); and

wherein the first service network node (421) is further configured to base the selection on one or more of:

a mobility pattern of the communication device (430);

an indication that the communication device (430) is close to handover between the first radio access node (41 1) served by the first service network node (421) and the second radio access node (412) adapted to be served by the one or more second service network nodes (422, 423, 424); the respective indication of whether or not the respective one or more second service network nodes (422, 423, 424) is able to admit migration of the service session (425); and

a load level of the first service network node (421) being above a threshold.

The first service network node (421) according to any of the claims 10-16, wherein first service network node (421) is configured to receive the indication that the second service network node (422, 423, 424) is able to admit migration of the service session (425) before the first service network node (421) has requested migration of the service session (425).

A method in a second service network node (422, 423, 424) for assisting a first service network node (421) in requesting migration of a service session (425) to the second service network node (422, 423, 424), wherein the service session (425) is associated with a communication device (430) in a wireless

communications network (400), and wherein the service session (425) is provided to the communication device (430) by a service application running in the first service network node (421), the method comprising:

sending (501 , 505, 701 , 703), to the first service network node (421), an indication of whether or not the second service network node (422, 423, 424) is able to admit migration of the service session (425), wherein the indication is sent without having received from the first service network node (421) a prior request to migrate the service session (425).

The method according to claim 18, wherein the indication of whether or not the second service network (422, 423, 424) is able to admit migration of the service session (425) comprises one or more of:

The method according to any of the claims 18-19, further comprising: receiving (503, 702) a request for admission control of migration of the service session (425) from the first service network node (421); and

sending (505, 703) the indication to the first service network node (421) in a response to the received request for admission control of migration of the service session (425), wherein the indication is an acceptance or a rejection of migration of the service session (425).

The method according to claim 20, further comprising:

preparing (506, 704) for migration of the service session (425) if the response comprises an acceptance of migration of the service session (425).

The method according to claim 21 , wherein preparing (506, 704) for migration of the service session (425) comprises loading code of the service application and/or configuration data of the service application from a slow memory to a fast memory.

A second service network node (422, 423, 424) configured to assist a first service network node (421) in requesting migration of a service session (425) to the second service network node (422, 423, 424), wherein the service session (425) is configured to be associated with a communication device (430) in a wireless communications network (400), and wherein the service session (425) is configured to be provided to the communication device (430) by a service application configured to run in the first service network node (421), and wherein the second service network node (422, 423, 424) is configured to:

send to the first service network node (421) an indication of whether or not the second service network node (422, 423, 424) is able to admit migration of the service session (425), and

send the indication without having received from the first service network node (421) a prior request to migrate the service session (425).

The second service network node (422, 423, 424) according to claim 23, wherein the indication of whether or not the second service network (422, 423, 424) is able to admit migration of the service session (425) comprises one or more of:

The second service network node (422, 423, 424) according to any of the claims 23-24, further configured to:

receive a request for admission control of migration of the service session (425) from the first service network node (421); and

send the indication to the first service network node (421) in a response to the received request for admission control of migration of the service session (425), wherein the indication is an acceptance or a rejection of migration of the service session (425).

The second service network node (422, 423, 424) according to claim 25, further configured to:

prepare for migration of the service session (425) if the response comprises an acceptance of migration of the service session (425).

The second service network node (422, 423, 424) according to claim 26, configured to prepare for migration of the service session (425) by loading code of the service application and/or configuration data of the service application from a slow memory to a fast memory.