Method and arrangement for supporting hand over of a mobile terminal

Network nodes in a source and a target communication system, and methods therein for supporting hand over to the target communication system, of a mobile terminal supporting Packet Switched-to-Circuit Switched, PS-to-CS, hand over. The method in the source communication system comprises, when requesting resources for hand over of a mobile terminal engaged in a conversational call to a target node in the target communication system, signaling a first request for PS resources to the target communication system, indicating a bearer B, used for the conversational call, and further signaling a second request for CS resources to the target communication system, indicating the bearer B. Thereby, the target communication system is enabled to decide whether a PS-to-CS HO or a PSHO of the bearer B should be performed.

TECHNICAL FIELD

The invention relates generally to Hand Over (HO) of a mobile terminal to a target cellular communication system, and in particular to supporting the same.

BACKGROUND

Single Radio Voice Call Continuation (SRVCC) is a Packet Switched (PS) to Circuit Switched (CS) HO mechanism, which is specified by 3GPP e.g. in TS 23.216.

An SRVCC is a service that allows an ongoing Voice over Internet Protocol (VoIP) call in LTE to be transferred to the CS domain. This service makes it possible for a VoIP call over LTE to be continued even if LTE coverage is lost.

An SRVCC can be seen as a PS-to-CS handover of a VoIP call. For performing SRVCC of e.g. a voice bearer to the CS domain, the VoIP telephony session needs to be anchored in the IP Multimedia Subsystem (IMS).

An SRVCC for a UE is typically triggered by an LTE eNB serving the UE, when the signal strength, received by the UE, from the eNB and other potential target LTE nodes drops below a certain threshold, i.e. when the UE experiences unfavorable LTE signal conditions, or ‘is having bad LTE coverage’.

The SRVCC mechanisms specified by 3GPP include two variants of handover from LTE to UTRAN, namely ‘CS only’, where only the voice bearer is handed over in a PS-to-CS HO, and other PS bearers are dropped; and ‘CS and PS’, where the voice bearer is handed over in a PS-to-CS HO and other PS bearers are handed over in a PSHO. The LTE eNB selects what type of SRVCC to request.

There is further a version of the SRVCC, called Single Radio Video Call Continuation (vSRVCC), which is also defined by 3GPP. As the name implies, vSRVCC relates to continuation of multimedia calls, or so-called “video calls”, anchored in IMS. Such video calls may also be referred to as VoIP+video calls, IMS video calls or similar. When using the term VoIP herein, as in VoIP bearer, etc. this also embraces VoIP bearers/conversational bearers of multimedia calls.

According to the current implementation of SRVCC in 3GPP, the process is started by the eNB when the eNB requests a HO to e.g. WCDMA or GSM and indicates in the HO required message that an SRVCC is needed.

One problem with the current implementation is that in order to request an SRVCC for a UE, the eNB needs to be aware of that the UE has an ongoing VoIP session and that this VoIP session is anchored in the IMS. However, a basic design principle for Radio Access Network (RAN) nodes, such as eNB, is that these nodes should be unaware of what different kind of services that the UE is using.

Thus, the current approach has led to some very strange attempts to make it possible for the eNB to request an SRVCC for a UE. For example, it has been decided that the radio bearer that is used for a VoIP call (or video call in case of vSRVCC), i.e. the bearer that can be subject to SRVCC, is the only bearer that can be assigned the Quality Class Indicator QCI=1. No other services are allowed to use this QCI value. According to the 3GPP specifications, the operator is free to use different QCI settings for different services, but in order for SRVCC to work, QCI=1 can only be used for VoIP (including VoIP+video) over IMS services. That is, the SRVCC design is not consistent with the common design principles.

SUMMARY

It would be desirable to have more flexibility in the HO procedure. The object of the solution described herein is to provide such flexibility.

In brief, the solution described herein involves moving decisions related to HO of a conversational bearer. The decision of whether a PS-to-CS HO is relevant or not, for a bearer of a UE is moved from the RBS serving the UE to a core network node of the source system. Further, a decision of whether a PS-to-CS HO or a PSHO of the bearer is to be performed is moved from the RBS to a node in the target system.

There are several advantages associated with the solution described herein. For example, an RBS in a HO source system will not need to be aware of the capabilities of a HO target system to which a UE is to be handed over. This means e.g. reduced need for configuration of external system cells and nodes in the RBS. In LTE terminology, the decision whether to request a PS-to-CS HO, such as SRVCC, or a PSHO is moved from the eNB to the MME.

Further, the PS-to-CS procedure according to the solution described herein will not depend on the use of QCI=1 for certain E-RABs, and thus the value CQI=1 will be free to use for bearers according to e.g. operator preferences.

Less configuration of neighborhood cells in the RBS will be required, as compared to legacy solutions. In particular, the RBS does not need to keep updated about e.g. what target system (e.g., UTRAN) cells/frequencies that support PS conversational RAB and if the target system supports IMS.

Further, the HO target system will be responsible for indicating e.g. SRVCC support in a reply to the HO source system, which means that such information does not have to be manually configured in the source system. Further, the target system decides which type of HO that is to be performed of a conversational bearer, and thus there is no risk of misalignment between the source and target systems. Further, load sharing is enabled between PS and CS in the target system, based on available PS versus CS resources. It is possible to keep the legacy SRVCC procedure in parallel, thus ensuring compatibility with legacy nodes and systems.

According to a first aspect, a method in a (source system) core network node (e.g. MME) is provided in a first cellular communication system. The first communication system supports packet switching (PS), and may be of e.g. LTE or WCDMA-type. The method is for supporting HO of a UE to a target cellular communication system, where the UE supports PS-to-CS HO. The method comprises, when requesting resources for HO of a UE engaged in a conversational call: signaling a first request for PS resources and a second request for CS resources to the target communication system, where both requests relate to/indicate the same bearer, B, used for the conversational call. Thus, the target communication system is enabled to decide whether a PS-to-CS HO or a PSHO of the bearer B should be performed.

According to a second aspect, a network node is provided. The network node is operable in a cellular communication system supporting PS communication. The network node is suitable for supporting HO of a UE to a target cellular communication system, where the UE supports PS-to-CS HO. The network node comprises a functional unit configured to, when requesting resources for HO of a UE that is engaged in a conversational call to a target node in the target communication system, signal a first request for PS resources and further signal a second request for CS resources to the target communication system, where both requests relate to/indicate the same bearer, B, used for the conversational call.

According to a third aspect, a method in a target network node is provided in a target cellular communication system. The method is for supporting HO of a UE supporting PS-to-CS HO to the network node. The target communication system supports both CS and PS communication. The method comprises receiving a first and a second request for resources for HO of a bearer, B, from a source communication system. One of the first and second requests is related to CSHO and the other to PSHO. The method further comprises deciding whether to accept the request related to CSHO or the request related to PSHO, based on a criterion related to capabilities of the target network node.

According to a fourth aspect, a network node is provided for supporting HO of a UE to the network node, where the UE supports PS-to-CS HO. The network node is operable to be a target network node in a cellular communication system and supports both CS and PS communication. The network node comprises a functional unit, which is configured to receive a first and a second request for resources for HO of a bearer, B, from a source communication system. One of the first and second requests is related to CSHO and the other is related to PSHO. The network node further comprises a functional unit, which is configured to decide whether to accept the request related to CSHO or the request related to PSHO, based on a criterion related to capabilities of the network node.

According to a fifth aspect, a method is provided in an RBS in a cellular communication system supporting PS communication. The method is for supporting HO, to a target cellular communication system, of a UE supporting PS-to-CS HO. The method comprises, when receiving information from the UE indicating a need for a HO to a target node in a target cellular communication system, it is determined whether the UE supports PS-to-CS HO. If the UE is found to support PS-to-CS HO, a request is signaled, to a core network node, for HO of the UE. The request indicates that the UE supports PS-to-CS HO, but it does not indicate which type of HO that should be used, in terms of CS or PS. Thus, the decision of whether to perform a PS-to-CS HO or a PSHO is left to one or more other network nodes. The RBS does not have knowledge of the capabilities, in terms of support of VoIP and IMS, of the target node.

According to a sixth aspect, an RBS is provided. The RBS is operable in a cellular communication system supporting PS communication. The RBS is suitable for supporting HO, to a target cellular communication system, of a UE, which supports PS-to-CS HO. The RBS comprises a functional unit, which is configured to determine, when the UE indicates a need for a HO to a target node, whether the UE supports PS-to-CS HO or not. The RBS further comprises a functional unit, configured to signal, if the UE is found to support PS-to-CS HO, a request for HO of the UE. The request indicates that the UE supports PS-to-CS HO, but it does not indicate which type of HO that should be used, in terms of CS or PS.

The methods and nodes described above may be implemented in different embodiments, which will be further described and exemplified herein.

DETAILED DESCRIPTION

Above one problem with the current implementation of SRVCC and vSRVCC is described. Another problem with the current implementation is a complexity issue. The eNB needs to be aware of the IMS capabilities of the nodes and cells in the target communication system. If the target cell is IMS and VoIP capable, there is no reason to perform a, from a network perspective, expensive complex operation like SRVCC. In that case a normal PSHO would be all that is needed.

The use of the solution suggested herein reduces the complexity and thereby the operational cost of supporting e.g. SRVCC and/or vSRVCC in an EPC/LTE system.

This is done in two ways:

Firstly: by enabling for the eNB to treat the SRVCC operation as a normal IRATHO. There is no need to restrict the number of E-RABs using QCI=1. The MME is already service aware, and this knowledge is utilized.

Secondly: by letting the target communication system allocate resources on a “best possible” basis in the IRATHO resource preparation phase, the source system does not need to keep track of whether the target system node or cell supports VoIP or not, i.e. no configuration of that is necessary. In case the target system supports VoIP anchored in IMS, the necessary PS resources are allocated and a pure PSHO is carried out. In case the target system does not support VoIP anchored in IMS, typically, both CS and PS resources are allocated and the SRVCC operation is carried out.

The alternative HO procedure suggested herein will henceforth be referred to as the “open CS or PS request procedure”.

When the MME sends a resource requirement, or request, to the target system, the requirement will be for resources for the conversational call, i.e. voice call or multimedia call. Based on the response from the target system, the MME initiates a normal PSHO or an SRVCC. The decision whether to initiate an SRVCC or not is thus moved from the eNB to the MME. The MME has knowledge of all services that a UE requests, and is thus aware of whether a UE is engaged in a conversational call or not. The MME is also informed of whether the UE supports e.g. SRVCC or not.

FIG. 1illustrates the signaling involved in an open CS or PS request procedure. The base forFIG. 1is picture 6.2.2.2-1 taken from the 3GPP specification of SRVCC, 23.216. The actions, messages and nodes that are modified according to the herein suggested solution have been marked with a delta, Δ. An action6c, which is not present in the original figure, has been added, surrounded by a dotted line.

The reference numbers inFIG. 1refer to the following actions or messages, which will also be further described below:1: Measurement reports2: Decision for HO (modified)3: Handover Required (modified)4: Bearer splitting, and UE service check (modified)5a: PS to CS Request5b: Prepare HO5c: Relocation/HO Request6a: Forward Relocation Request (modified)6b: Relocation/HO Request6c: Deciding Process (new)7a: Relocation/HO Request Acknowledgement7b: Forward Relocation Response8a: Relocation/HO Request Acknowledgement8b: Prepare HO response8c. Establish circuit9: Initiation of Session Transfer (STN-SR or E-STN-SR)10: Session transfer and update11: Release of IMS access12: PS to CS Response (interpretation modified)13: HO Command14: HO from EUTRAN Command

For simplicity, the node104, denoted Source E-UTRAN inFIG. 1will be referred to as “eNB”, and the node114, denoted Target RNS/BSS inFIG. 1will be referred to as “RNC”, thus using an UMTS system as an example of the target communication system.

The eNB104receives information1from a UE102, indicating a need for a HO to another identified system, which provides better radio conditions at the location of the UE. The eNB104then determines2whether the UE102supports PS-to-CS HO. If the UE104does not support PS-to-CS HO, the “open PS or CS” solution described herein is not applicable, and a conventional PSHO may be requested (or not) (not illustrated inFIG. 1). However, if the UE supports PS-to-CS HO, the eNB sends a request3for HO to an MME106. The eNB104does not need to know whether the UE102is engaged in a conversational call, or what the capabilities of the target system are, in terms of support of VoIP and IMS (which it has to know in the legacy procedure).

The MME106thus receives a request3for a HO to a target communication system of the UE102, which supports PS-to-CS HO. If the UE102is engaged in a conversational call, a PS-to-CS HO may be motivated. The MME106determines4whether the UE102is engaged in a conversational call, based on information related to the services of the UE, which is available within the MME106. The MME splits4the bearers into conversational bearer(s) and non-conversational bearers then transmits one request5afor PS-to-CS HO of the conversational bearer(s), and one request6afor PSHO. The difference to the legacy procedure is that the conversational bearers are included in the request6afor PSHO, i.e. the conversational bearers are included in both requests5aand6a.

The requests5aand6areaches, via messages5b,5cand6b, the target node, RNC114. The RNC is aware of its capacities, e.g. whether it supports CS communication, VoIP anchored in IMS, and whether it has available PS and/or CS resources. The RNC114decides6cwhether the HO should be accepted, and whether the conversational bearers should be handed over by PS-to-CS HO or PSHO (PS-to-PS). The decision may be made based on the capacities of the RNC114. The RNC then indicates7a,8awhether the conversational bearers are accepted for PS-to-CS HO or for PSHO. The indication reaches the MME106in form of messages7band12inFIG. 1. The MME106may then proceed with a HO procedure in accordance with the received indication. The message12, even though indicated with a delta Δ, is not necessarily modified as such; it may still have the same standard appearance. However, the interpretation of the information of the message is modified in that the HO procedure may be deemed to be successful even when the request for CS resources (PS-to-CS HO) is rejected (e.g. a PSHO may successfully be performed instead). According to the legacy procedure, the HO procedure was only deemed to be successful if the request for CS resources was accepted.

Thus, the message S1AP HANDOVER REQUIRED, “3” inFIG. 1, which is sent to the MME106by the eNB104, may result in either a PSHO of all bearers associated with the UE102, or, a PS-to-CS HO of the conversational bearers, possibly accompanied by a PSHO of the remaining, non-conversational bearers. When the S1AP HANDOVER REQUIRED command3is received from the eNB104, the MME106needs to determine whether any of the bearers associated with the UE (which needs to perform a HO) are used for VoIP data or multimedia call data (VoIP+video). The MME106would also perform applicable license checks.

When the MME receives the HANDOVER REQUIRED command3from the eNB, it should perform the following check:Is the UE SRVCC capable?Are any of the bearers involved in the HO used for a VoIP (or video call) session anchored in the IMS?

Further, in order for the solution to be compatible with legacy procedures, an Information Element (IE), or indicator, sometimes denoted ‘SRVCC HO Indication’, may be set by the eNB104in the HANDOVER REQUIRED command3. The IE could be set to indicate ‘CS only’ or ‘CS and PS’, where ‘CS only’ could indicate legacy procedure, and ‘CS and PS’ could indicate the suggested open CS or PS procedure. It could be determined by the MME106whether the IE have value=‘CS and PS’ or ‘CS only’, and action may be taken in accordance with the result of the determining, e.g. as exemplified in the table below:

Note that, as specified by 3GPP, in the case legacy SRVCC ‘CS only’ is triggered, and the target system is GSM, eNB also indicates to MME that PS RABs shall be suspended.

MME106and RNC114need to know that the ‘open CS or PS request procedure’ is to be performed. However, it can be carried out by using the current standardized messages as described above and exemplified inFIG. 1.

As in the legacy implementation, the MME106will perform a bearer splitting, which is needed in order to separate the conversational (VoIP) component from the other PS bearers. However, in the suggested solution, the MME will also keep information needed for the parallel track of performing a pure PSHO of all E-RABs associated with the UE in question, including the VoIP bearer.

SRVCC (PS-to-CS) preparations shall be initiated quickly. But, the MME shall not do anything that cannot later be canceled depending on the response from the target RNC. The MME will thus send a resource request to the target system that does not restrict the HO, or relocation, to either of SRVCC or PSHO. Both alternatives shall still be possible. This is accomplished by sending two requests, as described above, and in more detail below:

1/a request to the Serving GPRS Support Node (SGSN) for all PS bearers (including the VoIP bearer) (cf. message6ainFIG. 1), and

2/a request to anchor Mobile Switching Centre (MSC) (over Sv interface) for a PS-to-CS handover for the VoIP bearer (or VoIP+video bearer) (cf. message5ainFIG. 1)

In the target system the RNC will receive one Radio Access Network Application Part (RANAP): Relocation request from the SGSN and one RANAP: Relocation Request from the MSC. These requests shall be coordinated according to legacy procedures specified e.g. in 3GPP TS 25.413. The difference between the suggested ‘open CS or PS request procedure’ and a legacy procedure for a ‘CS and PS’ IRATHO or SRVCC is that in the suggested ‘open CS or PS request procedure’, resources for the VoIP (or VoIP+video for video call) bearer are included in both messages. RNC will identify the PS RAB that is requested for the VoIP bearer by that the IE traffic class in the PS RAB parameters is set to ‘conversational’.

RNC may then allocate resources on a ‘best possible’ basis, e.g.:In case of support for VoIP (VoIP-only anchored in IMS and/or video call anchored in IMS): RNC allocates PS resources and rejects resource requests for CS.In case of no support for VoIP: RNC allocates CS resources for the VoIP bearers and allocates PS bearers for other RABs.
Subsequently, based on the reply from the RNC, the MME may:In case of support for VoIP in target system: Initiate PSHO and cancel the initiated SRVCC (PS-to-CS) operation.In case of no support for VoIP in target system: Initiate SRVCC.
RNC also has the freedom to allocate resources in any other cell than the one suggested by eNB. If, for example, VoIP is supported in a co-located cell, resources may be allocated in this co-located cell.

FIGS. 2 and 3show an alternative illustration of the ‘open CS or PS request procedure’, partly comprising more details thanFIG. 1. The reference numbers inFIGS. 2 and 3refer to the following actions:1: UE is EPS attached in HSS and IMS registered2: Active IMS VoIP call3: eNB receives measurements from UE related to 2G/3G and LTE signal4: eNB requests SRVCC HO5: MME splits voice and non-voice bearer and initiates HO to 2G/3G6a: SGSN allocates PS resources for HO to 2G/3G and initiates bearer transfer from MME (parallel to CS)6b: Anchor MSC initiates session transfer from IMS and selects target MSC. Target MSC allocates CS resources for HO to 2G/3G (parallel to PS)6c: RNC selects which request (cf.6aand6b) to accept, if any.6d: RNC responds in accordance with selection.7: UE tunes to 2G/3G and call continues e.g. on CS; PS is continued in 3G or 2G with DTM, otherwise suspended.7a: SGSN requests PS resources for all bearers, including VoIP bearer.7b: Target MSC requests CS resources for voice bearer8: RNC selects which request (cf.7aand7b) to accept, if any, and responds accordingly.
Alignment with Legacy Procedure

To simplify implementation of the solution suggested herein, and alignment with legacy functionality may be advantageous. For example, an MME or RNC which is upgraded to enable the open CS or PS request procedure may also be made capable of handling the legacy PS-to-CS procedure, e.g. legacy requests to and from legacy nodes which are not upgraded to the open CS or PS request procedure.

An exemplifying procedure in a network node, having the role of the MME in the examples above, will be described below with reference toFIG. 4. A request for a HO of a UE to a target communication system is received in an action402. The target communication system may be a system using another Radio Access Technology (RAT), or a system of the same type as the source system, operated by another operator. Thus, the HO could be an Inter RAT HO (IRAT), e.g. from an LTE system to a WCDMA system, or an Intra RAT HO, e.g. between two WCDMA systems operated by different operators. It is determined in an action404, whether the UE supports PS-to-CS HO, e.g. SRVCC and/or vSRVCC, or not. Such information is included in the HO request. If the UE does not support PS-to-CS HO, a PSHO may be initiated in an action407. If the UE supports PS-to-CS HO, it is determined whether the UE is engaged in a conversational call or not in an action406. If the UE is not engaged in a conversational call, a PSHO may be initiated in an action407. The actions404and406could alternatively be performed e.g. in parallel or in the reverse order.

If the UE supports PS-to-CS HO and is engaged in a conversational call, two requests are signaled to a target communication system in an action408. The requests may be described as requests for resources for HO, or as request for HO, and are a part of a HO preparation phase. One of the requests relates to PS resources and indicates a bearer, B, used for the conversational call (and possibly other bearers as well). The other request relates to CS resources, and also indicates the bearer, B. By the above procedure, the target communication system, or target node, is enabled to decide whether a PS-to-CS or a PSHO should be performed (in legacy procedures, this is decided by the RBS in the source communication system).

Further, an indication may be received in an action410as a response to the first and second request. Based on the indication, the type of HO to be performed may be determined in an action412, and said type of HO may be triggered, or initiated, in an action414.

The conversational call is assumed to be anchored in the IMS, and to involve VoIP. The conversational call could be a regular voice call (voice only) or a multimedia call involving e.g. visual information, such as video. The type of PS-to-CS HO supported by the UE could be e.g. SRVCC and/or vSRVCC, or similar procedures being differently denoted.

Below, an exemplifying network node501, e.g. an MME in an LTE system, configured to enable the performance of the above-described procedure will be described with reference toFIG. 5. The network node501is operable in a PS cellular communication system. The network node501is suitable for supporting HO, to a target cellular communication system, of a mobile terminal, UE, supporting PS-to-CS HO.

The network node501is illustrated as to communicate with other entities via a communication unit502, which may be considered to comprise means for wireless and/or wired communication. The parts of the network node501which are configured to enable the performance of the above-described procedure are illustrated as an arrangement500, surrounded by a dashed line. The arrangement500and/or network node501may further comprise other functional units512, for providing e.g. regular functions. The arrangement and/or network node may further comprise one or more storage units510.

The arrangement500could be implemented by processing circuitry, e.g. by one or more of: a processor or a micro processor and adequate software (and storage therefore), a Programmable Logic Device (PLD) or other electronic component(s)/processing circuit(s) configured to perform the actions mentioned above in conjunction withFIG. 4.

The arrangement500may be implemented and/or described as follows: The arrangement500may comprise a signaling unit508, which is configured to signal a first and a second request to a target communication system, when requesting resources for HO of a UE, engaged in a conversational call, to a target node in the target communication system. The first request relates to PS resources, and indicates a bearer, B, which is used for the conversational call. The first request for PS resources may indicate all Radio Access Bearers (RABs) associated with the UE. The second request relates to CS resources, and also indicates the bearer, B, which is used for the conversational call. The terminology “first” and “second” in relation to the requests does not necessarily indicate a corresponding chronological order of the signaling of the requests, but is only used for separating the requests. The arrangement500and the network node501comprising the arrangement are thereby configured to enable the target communication system to decide whether a PS-to-CS HO or a PSHO of the bearer B should be performed.

The arrangement500in the network node501may further comprise a receiving unit504, configured to receive an indication from the target communication system, as a response to the first and second request. The arrangement500may further comprise a determining unit506, configured to determine whether to trigger a PS-to-CS HO or a PSHO of the bearer B of the UE to the target node, based on the received indication. As described above, the HO could be an IRAT or an Intra RAT HO.

The arrangement500may further comprise a triggering unit509, configured to trigger a PSHO and canceling the initiated PS-to-CS operation when a received indication indicates that the target node accepts the (first) request for PS resources; and further configured to trigger a PS-to-CS HO when a received indication indicates that the target node accepts the (second) request for CS resources. The term ‘triggering’ could alternatively be exchanged for ‘initiating’ or similar.

An exemplifying procedure in a network node, having the role of the target network node in the examples above, will be described below with reference toFIG. 6. The network node may be e.g. an RNC in a WCDMA-type system. The method is suitable for supporting HO of a UE, which supports PS-to-CS HO, e.g. SRVCC, and/or vSRVCC, from a source communication system to the network node. The network node501supports both CS and PS communication. The source communication system may e.g. be of LTE-type or of WCDMA-type.

A request for CS resources and a request for PS resources for HO are received from a source communication system in an action602. The requests both indicate a bearer B, used for a conversational call that is to be handed over. The source communication system supports PS communication and may be a system using another RAT, or a system of the same type as the source system, operated by another operator. Thus, the HO could be an IRAT or an Intra RAT HO.

Further, it is decided in actions604and608, whether to accept the request for CS resources, i.e. related to CSHO, or the request for PSHO, i.e. related to PSHO, based on a criterion related to capabilities of the network node. The capabilities may involve e.g. support of VoIP and IMS and/or current CS and/or PS capacity or load.

The decision of which request to accept, and thus of which type of HO that should be performed may then be indicated to the source communication system, e.g. in one or more of actions605,606,609,610, illustrated inFIG. 6. For example, the decision may result in that the request for PS resources is rejected, e.g. in an action606, and the request for CS resources is accepted, e.g. in an action610, and thus it is indicated to the source communication system that a PS- to CS HO is to be performed. Alternatively, the request for PS resources is accepted, e.g. in an action605, and the request for CS resources is rejected, e.g. in an action605or609, thus indicating to the source communication system that a PSHO is to be performed. Both requests could be rejected, e.g. if the network node does not have capacity to accept a HO. One type of request may be given priority over the other. Alternatively, some other type of indication may be used, e.g. a special message.

Below, an exemplifying network node701configured to enable the performance of the above described procedure related to a target network node, will be described with reference toFIG. 7. The network node may be e.g. an RNC in an UMTS-type system, such as WCDMA, The network node701is suitable for supporting HO of a UE, which supports PS-to-CS HO, e.g. SRVCC, and/or vSRVCC, from a source communication system to the network node701. The network node701supports both CS and PS communication.

The network node701is illustrated as to communicate with other entities via a communication unit702, which may be considered to comprise means for wired and/or wireless communication. The parts of the network node701which are configured to enable the performance of the above-described procedure are illustrated as an arrangement700, surrounded by a dashed line. The arrangement700and/or network node701may further comprise other functional units712, for providing e.g. regular functions. The arrangement and/or network node may further comprise one or more storage units710.

The arrangement700could be implemented by processing circuitry, e.g. by one or more of: a processor or a micro processor and adequate software (and storage therefore), a Programmable Logic Device (PLD) or other electronic component(s)/processing circuit(s) configured to perform the actions mentioned above in conjunction withFIG. 6.

The arrangement700may be implemented and/or described as follows: The arrangement700, and thus the network node710comprising the arrangement, may comprise a receiving unit704, configured to receive a first and a second request for resources for HO of a bearer, B, from a source communication system. One of the first and second requests is related to CSHO and the other to PSHO. The arrangement700may further comprise a deciding unit506, configured to decide whether to accept the request for CSHO or the request for PSHO, based on a criterion related to capabilities of the network node, as described above.

The arrangement700may further comprise an indicating unit708, configured to indicate the decided type of HO to the source communication system, e.g. by accepting the request related to one type of HO and rejecting the request related to the other type of HO.

An exemplifying procedure in an RBS801in a PS cellular communication system will be described below with reference toFIG. 8. The RBS may be e.g. an eNB in an LTE-type system. The method is suitable for supporting Hand Over, HO, to a target cellular communication system, of a UE, which supports PS-to-CS HO, such as SRVCC and/or vSRVCC. For specificities of the target and source system it is referred to the previously described examples related to said systems and nodes.

Information from a UE, indicating a need for a HO to a target node in a target cellular communication system may be received in an action802. Further, it is determined, in an action804, whether the UE supports PS-to-CS HO. If the UE does not support PS-to-CS HO, a PSHO may be requested in an action803. If the UE supports PS-to-CS HO, an ‘open PS or CS’ HO may be requested in an action812, by signaling a HO request for the UE, and indicating in the request that the UE supports PS-to-CS HO. By use of the solution provided herein, several actions that are performed in legacy procedures can be omitted, which is a great benefit. These omitted actions are illustrated as ‘non-actions’806-810inFIG. 8. Thus, it is not determined or indicated whether the UE is engaged in a conversational call. Further, the capabilities of the target node, e.g. in terms of support of VoIP or IMS are not determined or considered. Further, it is not determined or indicated which type of HO that should be used, in terms of CS or PS. Thus, the decision of whether to perform a PS-to-CS HO or a PSHO is left to one or more other network nodes.

Below, an exemplifying RBS901configured to enable the performance of the above described procedure related to an RBS, will be described with reference toFIG. 9. The RBS may be e.g. an eNB in an LTE-type system. The RBS901is suitable for supporting HO of a UE (served by the RBS), which supports PS-to-CS HO, to a target communication system. The RBS901supports PS communication.

The RBS901is illustrated as to communicate with other entities via a communication unit902, which may be considered to comprise means for wireless and/or wired communication. The parts of the network node701which are configured to enable the performance of the above-described procedure are illustrated as an arrangement900, surrounded by a dashed line. The arrangement900and/or RBS901may further comprise other functional units912, for providing e.g. regular RBS functions. The arrangement and/or network node may further comprise one or more storage units910.

The arrangement900could be implemented by processing circuitry, e.g. by one or more of: a processor or a micro processor and adequate software (and storage therefore), a Programmable Logic Device (PLD) or other electronic component(s)/processing circuit(s) configured to perform the actions mentioned above in conjunction withFIG. 8.

The arrangement900may be implemented and/or described as follows: The arrangement900, and thus the RBS910comprising the arrangement, may comprise a determining unit906, configured to determine, when a UE (served by the RBS) indicates a need for a HO to a target node in a target cellular communication system, whether the UE supports PS-to-CS HO, such as SRVSS and/or vSRVCC. The arrangement900may further comprise a signaling unit908configured to signal, if the UE supports PS-to-CS HO, a request for HO of the UE, indicating that the UE supports PS-to-CS HO. The signaling unit908, or any other unit, is not configured to determine or indicate whether the UE is engaged in a conversational call. Further, no unit is configured to determine or consider the capabilities of the target node, e.g. in terms of support of VoIP and IMS. Further, no unit is configured to determine or indicate which type of HO that should be used, in terms of CS or PS. Thus, the decision of whether to perform a PS-to-CS HO or a PSHO is left to one or more other network nodes.

FIG. 10schematically shows a possible embodiment of an arrangement1000, which also can be an alternative way of disclosing an embodiment of the arrangement illustrated in any ofFIG. 5,7or9. Comprised in the arrangement1000are here a processing unit1006, e.g. with a DSP (Digital Signal Processor). The processing unit1006may be a single unit or a plurality of units to perform different actions of procedures described herein. The arrangement1000may also comprise an input unit1002for receiving signals from other entities, and an output unit1004for providing signal(s) to other entities. The input unit1002and the output unit1004may be arranged as an integrated entity.

Furthermore, the arrangement1000comprises at least one computer program product1008in the form of a non-volatile memory, e.g. an EEPROM (Electrically Erasable Programmable Read-Only Memory), a flash memory and a hard drive. The computer program product1008comprises a computer program1010, which comprises code means, which when executed in the processing unit1006in the arrangement1000causes the arrangement and/or a node in which the arrangement is comprised to perform the actions e.g. of one of the procedures described earlier in conjunction withFIGS. 4,6and8.

The computer program1010may be configured as a computer program code structured in computer program modules. Hence, in an exemplifying embodiment, where the arrangement should be configured to perform the actions of one of the procedure described in conjunction withFIG. 4, the code means in the computer program1010of the arrangement1000may comprise a signaling module1010a, for signaling a first and a second request to a target communication system. The arrangement1000may further comprise a receiving module1010bfor receiving an indication from the target communication system, as a response to the first and second request. The computer program may further comprise a determining module1010cfor determining whether to trigger a PS-to-CS HO or a PSHO to the target node. The computer program1010may further comprise a triggering module1010dfor triggering the appropriate type of HO.

The modules1010a-dcould essentially perform the actions of the flow illustrated inFIG. 4, to emulate the arrangement illustrated inFIG. 5. It is to be understood that corresponding arrangements for performing the actions of the procedures illustrated inFIGS. 6 and 8, may be implemented.

Although the code means in the embodiment disclosed above in conjunction withFIG. 10are implemented as computer program modules which when executed in the processing unit causes the decoder to perform the actions described above in the conjunction with figures mentioned above, at least one of the code means may in alternative embodiments be implemented at least partly as hardware circuits.

It is to be understood that the choice of interacting units or modules, as well as the naming of the units are only for exemplifying purpose, and nodes suitable to execute any of the methods described above may be configured in a plurality of alternative ways in order to be able to execute the suggested process actions.

ABBREVIATIONS

EPS Evolved Packet System (EPS=LTE RAN+EPC)

E-UTRAN Evolved Universal Terrestrial Radio Access Network

LTE Long Term Evolution (used synonymously with E-UTRA)

MME Mobility Management Entity

PDN Packet Data Network

SRVCC Single Radio Voice Call Continuity

QCI QoS Class Identifier

vSRVCC Single Radio Video Call Continuity