There are some basic forms of network preferences in existing IMS procedures e.g. it is possible to redirect a UE to use the CS domain for emergency calls and forbid the use of IMS for emergency calls. However, when these are considered in VCC these do not make too much sense since in order to perform VCC you must be allowed to establish emergency calls in both CS and IMS. However, a network operator may still have a preference as to which domain an emergency call ought to be on. It is necessary to consider how these preferences relate to decision to transition from one access to the next. One key question is whether the network preferences take precedence over other typical reasons for transition e.g. degrading radio conditions. It is envisioned/assumed that device management is used to configure the different network preferences, but does this also extend to the other triggers It is necessary to specify what are the likely trigger conditions for a transition, since this a safety critical service and needs to be error-free. The type of handover is different from normal 3GPP radio level handover since VCC is UE triggered, but still need to be equally detailed (e.g. signal strength hysteresis regimes).

Taking a comparison with mobility in a "normal" mode of operation, it is possible to apply access restrictions during mobility. This ought to be equally true in the emergency call scenario, although the reason behind such restrictions during mobility will be different. In direct relation to the above topic of network preferences, there may be certain scenarios where a visited operator prefers to have emergency calls in CS (due to a CS only PSAP potentially) and as such the need for CS to IMS domain transfer is unclear. One could also consider that CS "coverage" is much greater than for the non-3GPP access that is using IMS for call establishment. Therefore the justification for CS to IMS transfers again is not so obvious.

The ability to perform the domain transfer on any call (irrespective of whether it is emergency or not) is driven by both network and UE capabilities. For non-emergency calls, typically no CS core network functionality is required since the solution is purely IMS driven. However in contrast for emergency calls, it is likely that CS core network functionality is required due to the need to carry information necessary for support of the UICC-less UE case across to IMS for anchoring during both call establishment and during domain transfer. Blind attempts by UEs (especially those in a limited service state i.e. no UICC or invalid credentials) to perform VCC transfer of emergency calls should be avoided where the UE cannot or has not established the status of the support of network features required. This is due to the undefined/unpredictable behaviour if the network does not support VCC features that may lead to call transfer failures or treatment as a new call establishment.

The anchoring of a call in IMS (at the E-SCC-AS) is vital to enable the transfer of the call from one domain to another. This concept does not change in VCC emergency. Anchoring of a CS call introduces call setup delay and increases network complexity (which ultimately leads to an increased probably of a failure). Therefore anchoring should not be considered to be applied for all calls but rather it should be avoided when the conditions allow for a call not to be anchored. The decision process must take into account all the points discussed in clauses 5.3.1, 5.3.2 and 5.3.3.

In (dual-radio) VCC (emergency or not), the trigger point for domain transfer is firmly at the UE. This needs to coexist with a basic principle that an initial emergency call is always established by the UE. However, when discussing this, it becomes important for the network to differentiate between any incoming call attempt as related to either a new call initiation or a domain transfer. For initial call establishment in CS, TS12 style signalling (i.e. Service Request = Emergency) will still be used as per TS 22.101. For domain transfers, the same signalling means may be used, however, this makes determination of the nature of the call very difficult without extensions. If a call is incorrectly identified, there is a possibility that there is no continuity and a new session / call (at user level) is established and the caller required to re-provide any information to a new operator (at the PSAP end). Furthermore, because of unexpected call termination for the old operator, they may attempt a call back which would almost certainly fail. If these potential error cases aren't avoided, there may be potential service interaction issues between 2 TS12 calls which had not been previously envisioned (even though there is a possibility for them to occur).

Due to the duty of care residing with the operator providing initial connectivity to the emergency services, it is generally not possible to transfer that duty from one operator to another. Also different operators may connect to different PSAPs which in turn may ultimate connect to a different set of physical operators. It is suggested that VCC for emergency calls are attempted only when the UE can identify that the source and target networks belong to the same network (operator). This ensures the continuity of an emergency call when performing domain transfers.