8 Cross Phase Compatibility for this release

22.1293GPPHandover requirements between UTRAN and GERAN or other radio systemsRelease 17Service aspectsTS

This section details the cross phase compatibility requirements relating to the service requirements in this document.

Note: When a change is introduced which affects the 3GPP technical specifications, it is said to be ‘backward compatible’ if existing equipment can continue to operate and perform correctly with equipment that conforms to the new implementation.

8.1 Compatibility with Existing Specifications

Where the service and operational requirements in this document relate to a GERAN, compatibility is required with systems conforming to the R99 or later GERAN specifications.

8.2 Compatibility with Future 3GPP specifications

The specifications that define the technical implementation of this release should be developed in such a way that it is practical to add the requirements in this section in a backward compatible manner.

8.2.1 Requirements for Service Capabilities

3GPP standardises service capabilities, not services. As part of the service capabilities it is envisaged that applications may wish to respond to events related to handover that either has occurred, is about to occur or could potentially occur. The service capabilities described in this section should be available at least to UE hosted applications.

The following list of uses is provided as an example and is not intended to be exhaustive:

– An application may wish to accept or reject offered QoS;

– An application may wish to cope to the effect that handover has on a service, for example facsimile retransmission;

– An application may wish to preferentially choose radio resources.

It is therefore required that the service capability set available to an application be able to provide an indication that handover has occurred or could occur with information about the type of handover and radio resources involved. The service capabilities should support QoS negotiation.

8.2.2 Inter PLMN Handover Issues

The minimum requirements for inter-PLMN HO are:

– The ability to check with the home network whether the user is permitted to handover from the visited network to a target network.

– Invocation of the handover procedure only occurs if the target network provides the radio channel type required for the respective call;

– The avoidance of "network hopping", i.e. successive handover procedures between neighbouring networks for the same call;

– The possibility of user notification of inter-PLMN HO (e.g. possible tariff change) when it occurs.

8.2.3 Handover between Environments

UMTS is expected to provide coverage in a number of environments including fixed and mobile as described in the table below. The technical specifications should not preclude the possibility of implementing these requirements in a backward compatible manner.

To From	Terrestrial Cellular	Fixed/Cordless	Satellite
Terrestrial Cellular	Yes (R99)	Yes	Yes
Fixed/Cordless	Yes	Yes	Yes
Satellite	Yes	Yes	No

8.3 Support of Multicall with Simultaneous Voice Calls

In the case where Multicall is used to support multiple voice calls a handover must be attempted for each bearer that is in use. In the case where not all bearers can be supported by the destination network the related voice calls shall be automatically put on hold. After the handover is completed, the subscriber shall be able to retrieve any held voice call by invoking the Call Hold service.

This requirement is dependent on the user subscribing to Call Hold.

This is only required if there is more than one simultaneous speech call and this is therefore not required for this release.

Annex A (informative):
Illustration of elements in inter-PLMN handover

Figure 1 illustrates the above definitions taking an example of European GSM networks. The subscriber’s home network is France. The visited network where the subscriber is registered in a VLR is Germany. The signalling connection between HLR and VLR is indicated by dotted lines. The calls for the subscriber are controlled by the MSC collocated to the VLR where the subscriber is registered. This MSC is called "anchor MSC".

Handover to a different MSC may occur if the cell serving the subscriber after handover is not controlled by the anchor MSC. This MSC is called the "serving MSC". Even after the call has been handed over to a different MSC, the call control function remains in the anchor MSC. The signalling connection and circuit switched connection established between anchor MSC and serving MSC are indicated by a solid line.

When the French subscriber registered in a German network roams near the border to the Netherlands, inter-PLMN handover may occur. In this case a Dutch network is the target network. After handover, the anchor MSC located in a German network continues to control the call. The German network remains the visited network where the subscriber is registered. The subscriber’s location information stored in the HLR remains unchanged. The signalling and circuit switched connections between the anchor MSC and the previously serving MSC in the German network will be released when the User Equipment (UE) is served by a cell within a Dutch network. The Dutch network becomes the serving network. From the Dutch network the subscriber may be handed over to a Belgian network.

Figure 1: Example for inter-PLMN handover

Annex B (informative):
Open Points on Inter-Operator Handover

The requirements outlined below are likely to need further elaboration, although these may be outside the scope of service requirements.