User plane solution has been developed in OMA based on IP to accommodate different radio accesses. Consequently, regardless of current attached access networks, as long as IP connection is available, then OMA solution works through direct communication between the location server and the UE. This protocol is called 'Secure User Plane Location: SUPL' and this seems to be well-suited to support LCS for non-3GPP accesses since naturally EPC is for All-IP. And this solution is also working for non-3GPP terminal for 3GPP2 and WiMAX and even WiMAX side already decided that SUPL would be used for location service. SUPL also rely on a support of transport of the initiation message ( SUPL INIT). The SUPL today mandates WAP Push over SMS (or HTTP) for 3GPP and SMS for 3GPP2. In addition SIP Push and UDP are optional. It is believed that there is no problem for 3GPP2 terminal to support SUPL.
If OMA SUPL is adopted, it seems obvious that there is no impact at all on EPC, however, it needs to consider other aspects such as the interaction between location servers in HPLMN and VPLMN to support the positioning of the UE in the VPLMN.
If the location server in VPLMN has a capability to calculate the position of the UE connected to non-3GPP access then the location server in the VPLMN may calculate the position of UE. But according to roaming agreement and operator policy, if the location server in the VPLMN cannot calculate the position of the UE connected to non-3GPP access, then VPLMN shall be possible to deliver assistance data to the location server in the HPLMN to calculate the position of the UE. The assistance data may consist of access specific information.
If the VPLMN does not have capabilities to calculate the position of UE connected to non-3GPP access then the location server in the VPLMN shall be possible to deliver the assistance data such as access specific parameters and so on to the location server in the HPLMN to calculate the position of UE.
To achieve these cases, the interface between the location server in VPLMN and the location server in HPLMN shall support the deliver of these assistance data such as access specific parameters. Historically, this interface was specified in the OMA and the protocol has been specified in the RLP 
In turn, in this TR, requirement discussed above can be specified, then OMA can discuss further gap analysis to meet this requirement as done that for LCS support for GSM / WCDMA such as MLP 
and RLP. MLP is stage 3 specification for the Le reference point 
and RLP is stage 3 specification for the Lr reference point 
. Additionally, RLP is an instantiation of a reference point between SUPL Providers with the purpose to transport information between SUPL Providers to enable positioning of roaming SUPL Enabled Terminals. Examples of such information are coarse position used when generating GPS assistance data or the actual GPS assistance data.
Quality of Serivice consists of horizontal accuray, vertical accuracy, response time and QoS class. Since OMA SUPL supports all aspects of QoS requirements, if OMA SUPL is used to locate non-3GPP terminals connected in EPC, then QoS requirements in OMA SUPL can be applied as it is.
Location requests for difference services may be processed with different levels of priority. For example, for value added services, the LCS server may allow different location requested to be assigned different levels of priority. This aspect is already supported in OMA SUPL.
Privacy requirements such as authorization of positioning attempts based on privacy profile, user permission requests and handling of permission responses from users, conditional positioning based on user's permission, conditional reporting based on user's location and so on are also supported in OMA SUPL. If OMA SUPL is used to locate non-3GPP terminals connected in EPC, then privacy requirements in OMA SUPL can be applied as it is.
Periodic location reporting specified in TS 22.071
is the act of the location server initiating multiple position locations spread over a period of time. OMA SUPL satisfies this requirement with the functionality called 'triggered location request', which enables to generate multiple location determinations of the target terminal at periodic intervals.