TS 24.304
Mobility Management based on Mobile IPv4 (MIPv4) –
User Equipment – Foreign Agent Interface

3GPP‑Page ETSI‑search CONTENT_↓

V18.0.0 (PDF) 2024/03 14 p.

V17.0.0 2022/03 14 p.

V16.0.0 2020/06 14 p.

V15.0.0 2018/06 13 p.

V14.0.0 2017/03 14 p.

V13.0.0 2015/12 14 p.

V12.0.0 2014/09 14 p.

V11.0.0 2012/09 14 p.

V10.0.0 2011/04 14 p.

V9.2.0 2011/04 14 p.

V8.2.0 2011/04 14 p.

Rapporteur:: Mr. Herrero-Veron, Christian
Huawei Technologies Co. Ltd.

Content for TS 24.304 Word version: 18.0.0

1 Scope p. 5

The present document describes the stage 3 aspects of mobility management for User Equipment (UE) using IETF Mobile IPv4 foreign agent mode to access the Evolved Packet Core Network (EPC) through trusted non-3GPP access networks and for mobility management of UE between the 3GPP access network and trusted non-3GPP access networks.

In particular, the present document describes the UE - Mobile IPv4 Foreign Agent (FA) interface stage 3 aspects, where the FA functionality is located within the access network in the non-3GPP access domain.

The present document is applicable to the User Equipment (UE) and the network node implementing the FA functionality.

2 References p. 5

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

RFC 5944 (November 2010): "IP Mobility Support for IPv4, revised".

[3]

TS 23.402: "Architecture enhancements for non-3GPP accesses".

[4]

TS 23.003: "Numbering, addressing and identification".

[5]

RFC 5446 (February 2009): "Service Selection for Mobile IPv4".

[6]

TS 33.402: "3GPP System Architecture Evolution; Security aspects for non-3GPP accesses".

[7]

RFC 2794 (January 2000): "Mobile IP Network Access Identifier Extension for IPv4".

[8]

TS 29.279: "Mobile IPv4 (MIPv4) based Mobility protocols; (Stage 3)".

[9]

RFC 3543 (August 2003): "Registration Revocation in Mobile IPv4".

3 Definitions and abbreviations p. 5

3.1 Definitions p. 5

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

Foreign Agent (FA):

a router on a visited network which provides mobile IPv4 routing services to the UE while registered as described in RFC 5944.

Foreign agent care-of address:

an address of a foreign agent with which the UE is registered as described in RFC 5944.

Home Agent (HA):

a mobile IPv4 router on a UE's home network which tunnels datagrams for delivery to the UE while it is registered on a visited network as described in RFC 5944. According to TS 23.402, the HA functionality is implemented in the PDN Gateway.

3.2 Abbreviations p. 6

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

EPC

Evolved Packet Core Network

Foreign Agent

FACoA

Foreign Agent Care-of Address

Home Agent

RRP

Registration Reply

RRQ

Registration Request

4 General p. 6

4.1 Mobility management based on FACoA p. 6

MIPv4 is specified in RFC 5944 which provides two alternative modes of enabling a mobile node (UE) to acquire a care-of address for routing of datagrams:

a "foreign agent care-of address" (FACoA) mode wherein a care-of address is provided by a FA through agent advertisement messages, or
a "co-located care-of address" mode wherein a care-of address is acquired by the UE as a local IP address.

For the purpose of IP mobility management while accessing the EPC through a trusted non-3GPP access network, the FACoA mode enables the UE to register the IP address of the FA (FACoA) located within the non-3GPP access network with the UE's HA for the routing of datagrams to the UE.

4.2 Identities p. 6

In order to support MIPv4 FA mode mobility management with the EPC, the network and mobile client shall use an NAI as described in TS 23.003 for user identification. The network and mobile client shall base the username part of the NAI on IMSI.

The network and UE shall use the Root NAI when the UE attempts a MIPv4 registration while attached to the HPLMN. The Root NAI format is specified in TS 23.003.

The network and UE shall use the Decorated NAI when the UE attempts a MIPv4 registration while attached to a VPLMN. The Decorated NAI format is specified in TS 23.003.

4.3 Multiple PDN connectivity p. 6

Following the establishment of a mobility binding to an initial PDN, the UE can request the establishment of a mobility binding with an additional PDN by including the APN of the desired PDN within a Service Selection extension defined in RFC 5446. The Service Selection extension is included within the Registration Request (RRQ) message defined in RFC 5944. The UE can repeat the process of sending an (RRQ) with a Service Selection extension to establish connectivity with additional PDNs.

4.4 MIPv4 security aspects p. 7

The procedures for bootstrapping of MIPv4 foreign agent care-of address (FACoA) security parameters are described in TS 33.402.

The MIPv4 security is based on the use of the authentication extensions defined in RFC 5944. The MIPv4 signalling messages are protected between the UE and the HA using the Mobile-Home Authentication extension and optionally between the UE and the FA using the Mobile-Foreign Authentication extension.

5 FACoA procedures for mobile IPv4 p. 7

5.1 FACoA initial attach and registration p. 7

5.1.1 General p. 7

The MIPv4 initial attach is performed by the UE to establish a MIPv4 connection with the node acting as the HA. The initial attach involves the following procedures:

Discovery of the HA address: The UE needs to discover the IPv4 address of the node acting as the HA.
Discovery of FACoA: The UE needs to discover the IPv4 care-of address provided by the FA.
IPv4 home address assignment: The UE needs to be assigned an IPv4 address to be used as the home address in Mobile IPv4 FACoA mode. The HA is responsible of assigning the home address to the UE.
Security association establishment: The UE needs to establish a security association with the node acting as the HA in order to secure the MIPv4 signalling. This procedure usually consists in a shared key verification and is performed via MIPv4 signalling.

5.1.2 UE procedures p. 7

5.1.2.1 Agent discovery p. 7

When the UE has attached to the non-3GPP access network, the UE may send a MIPv4 Agent Solicitation as specified in RFC 5944.

5.1.2.2 FACoA registration p. 7

Upon first receiving a MIPv4 Agent Advertisement message from a FA or detecting a reboot of the FA through inspection of the Agent Advertisement message sequence number, the UE shall select one care-of address included in the Mobility Agent Advertisement Extension and shall send an RRQ to the FA as specified in RFC 5944 with the care-of address included in the Care-of Address field of the RRQ message. The UE shall set the source address and Home Address field to the unspecified address (i.e. 0.0.0.0). The UE shall clear bits S (simultaneous binding) and D (decapsulation by mobile node), and set bit T (reverse tunnelling) to request reverse tunnelling. The UE shall also include the NAI extension as specified in RFC 2794.

As part of MIPv4 security, the UE shall include the Mobile-Home Authentication extension within the RRQ as specified in RFC 5944. The UE shall set the authenticator and SPI fields of the of the Mobile-Home authentication extension to the MN-HA key and associated MN-HA-SPI generated as described in TS 33.402. If the non-3GPP access specific procedures require a security association between the UE and FA, the UE shall also include the Mobile-Foreign Authentication extension within the RRQ as specified in RFC 5944. The UE shall set the authenticator and SPI fields of the of the Mobile-Foreign authentication extension to the MN-FA key and associated MN-FA-SPI generated as described in TS 33.402.

If the UE already knows the IP address of the HA (e.g. when the HA address is pre-configured) the UE shall include that IP address in the Home Agent field.

If the UE does not know the IP address of the HA, the UE shall include the unspecified address (i.e. 0.0.0.0) in the Home Agent field.

If the UE has established a mobility binding with a given PDN and connection to an additional PDN is desired, the UE shall include the APN of the desired PDN within a Service Selection extension as defined in RFC 5446 within an RRQ as described in RFC 5944.

If the UE is registered on a trusted non-3GPP access network and maintenance of its registered mobility binding is desired, the UE shall re-register before the expiration of the lifetime of the registration as specified in RFC 5944. If the UE has established connectivity to multiple PDNs, the UE shall re-register all mobility bindings.

When the UE receives a Registration Reply (RRP) from the FA, the UE shall perform the validity checks and process the message as specified in RFC 5944 to include validation of the Mobile-Home Authentication extension and, if present, the Mobile-Foreign Authentication extension. After receiving a successful RRP, the UE shall store the HA address and the home address and may send data using the home address.

5.1.3 FA procedures p. 8

5.1.3.1 Agent advertisement p. 8

When the FA receives a MIPv4 Agent Solicitation, the FA shall send a MIPv4 Agent Advertisement to the UE as specified in RFC 5944. The MIPv4 Agent Advertisement shall include only the Mobility Agent Advertisement Extension.

The FA shall send an unsolicited MIPv4Agent Advertisement when it receives a trigger that a new UE has attached to its link and it has not received a MIPv4 Agent Solicitation from the UE. In this case the FA shall set the destination address of the MIPv4Agent Advertisement shall be the "limited broadcast" address (i.e. 255.255.255.255).

For both solicited and unsolicited MIPv4Agent Advertisements, the FA shall set the following bits in the Mobility Agent Advertisement Extension: R (registration required), F (foreign agent) and T (reverse tunnelling) (see RFC 5944). The FA shall include at least one care-of address in the Mobility Agent Advertisement Extension.

5.1.3.2 UE registration p. 8

When the FA receives an RRQ from the UE, the FA shall process it as specified in RFC 5944 and TS 29.279. The FA shall validate the Mobile-Foreign Authentication extension if present.

If the RRQ is accepted by the network, the FA shall send an RRP to the UE as specified in RFC 5944. If the non-3GPP access specific procedures require a security association between the UE and FA, the FA shall also include the Mobile-Foreign Authentication extension within the RRQ as specified in RFC 5944. The FA shall set the authenticator and SPI fields of the Mobile-Foreign Authentication extension to the MN-FA key and associated MN-FA-SPI generated as described in TS 33.402.

5.2 FACoA handover p. 8

5.2.1 General p. 8

A MIPv4 handover occurs when the UE changes access between trusted non-3GPP accesses. A change in the local point of attachment will trigger a MIPv4 handover procedure. In this case, the UE has already an established binding at the HA, and the handover procedure will update the care-of address (FA IP address) of its binding.

5.2.2 UE procedures p. 8

The UE may detect a movement, based on the ICMP Lifetime field of the router advertisements: if the lifetime of an agent advertisement has expired, and the UE has not received another Agent Advertisement message from the same FA, then the UE can consider itself having moved.

Another method for the UE to discover that it has moved is based on the advertised prefix: a change in the advertised prefix can aid the UE in determining that it has moved and to register with the newly advertised prefix. This method is only used when all mobility agents use the prefix length extension in their agent advertisements.

Upon detecting movement, the UE shall register with the new FA as specified in RFC 5944 by sending an RRQ with the care-of address of the new FA included in the Care-of Address field of the message. The UE shall set the source address to the unspecified address (i.e. 0.0.0.0). The UE shall clear bits S (simultaneous binding) and D (decapsulation by mobile node), and set bit T (reverse tunnelling) to request reverse tunnelling. The UE shall also include the NAI extension as specified in RFC 2794.

If the UE had maintained connectivity to multiple PDNs prior to the handover, the UE shall then update its mobility binding with each additional PDN using the procedure described in subclause 5.1.2.2.

The UE shall include its known home address and the IP address of the HA within the RRQ.

5.2.3 FA procedures p. 9

The FA shall respond to agent solicitations sent by the UE, by addressing these agent solicitations to the unicast layer 2 and layer 3 addresses.

When the FA receives a RRQ from the UE, the FA shall process it as specified in RFC 5944 and TS 29.279. The FA shall validate the Mobile-Foreign Authentication extension if present.

The FA relays the RRQ to the HA IP address found in the registration message.

If the network accepts the RRQ, the FA shall send an RRP to the UE as specified in RFC 5944. If the non-3GPP access specific procedures require a security association between the UE and FA, the FA shall also include the Mobile-Foreign Authentication extension within the RRQ as specified in RFC 5944. The FA shall set the authenticator and SPI fields of the Mobile-Foreign Authentication extension to the MN-FA key and associated MN-FA-SPI generated as described in TS 33.402.

5.3 FACoA deregistration p. 9

5.3.1 General p. 9

MIPv4 deregistration is either due to a detach or a return home event.

When the UE returns home, it will need to deregister from the HA. This can occur when the UE returns to the 3GPP network. In this scenario, the UE will de-register from the PDN-GW acting as an HA.

5.3.2 UE procedures p. 9

5.3.2.1 Network-initiated deregistration p. 9

Network-initiated deregistration can occur due to an administrative reason or detecting the UE's leaving the trusted non-3GPP access network. Network-initiated deregistration takes the form of registration revocation as defined in RFC 3543. The FA or the HA can initiate registration revocation.

The UE can be informed that its mobility binding no longer exists through inspection of the Agent Advertisement sequence number as described in RFC 5944.

Upon determining that its mobility binding no longer exists with the FA and HA, the UE shall locally clear its mobility binding.

5.3.2.2 UE-initiated deregistration p. 10

The UE deregisters from its HA when it determines that it is back home or as part of a UE-initiated detach from the serving trusted non-3GPP access network. The UE can determine that it is back home through inspection of the H bit and advertised prefix within a received agent advertisement.

In the case of UE deregistration upon returning home, the UE sends an RRQ with the destination address set to the HA's address, with a Lifetime field set to 0 to indicate deregistration, and with the care-of address set to the UE's home IP address. The RRQ will be formatted and handled as specified in RFC 5944. The UE shall include the Mobile-Home Authentication extension within the RRQ as specified in RFC 5944 and shall set the authenticator and SPI fields of the of the authentication extension to the MN-HA key and associated MN-HA-SPI generated as described in TS 33.402.

In the case of UE deregistration as part of a UE-initiated detach from the serving trusted non-3GPP access network, the UE sends an RRQ with the Destination Address field set to the FA's address, with a Lifetime field set to 0 to indicate deregistration, and with the Care-of Address field set to the FA care-of address previously registered with the HA. The RRQ will be formatted and handled as specified in RFC 5944. The UE shall include the Mobile-Home Authentication extension within the RRQ as specified in RFC 5944 and shall set the authenticator and SPI fields of the of the authentication extension to the MN-HA key and associated MN-HA-SPI generated as described in TS 33.402. If the non-3GPP access specific procedures require a security association between the UE and FA, the UE shall also include the Mobile-Foreign Authentication extension within the RRQ as specified in RFC 5944 and shall set the authenticator and SPI fields of the Mobile-Foreign Authentication extension to the MN-FA key and associated MN-FA-SPI generated as described in TS 33.402.

If the UE has established connectivity to multiple PDNs, the UE shall perform this deregistration process for each PDN. The UE shall include a Service Selection extension as defined in RFC 5446 denoting the APN of the PDN to be deregistered in the RRQ.

Once the deregistration request is accepted, the UE receives an RRP directly from the HA in the case of a "back home" deregistration or from the HA through the FA in the case of a deregistration as part of a UE initiated detach in the serving non-3GPP access network. The UE shall perform the validity checks on the Mobile-Home Authentication extension, and, if present, the Mobile-Foreign Authentication extension and processes the message as specified in RFC 5944.

5.3.3 FA procedures p. 10

5.3.3.1 Network-initiated deregistration p. 10

The FA can initiate deregistration by sending a Registration Revocation message, as defined in RFC 3543, to the address of the HA. The Source Address field will be the care-of address of the FA registered by the UE, and the Home Address field will be the home IP address of the UE whose registration is being revoked. The HA will respond with a Registration Revocation Acknowledge message as specified in RFC 3543.

The HA can initiate deregistration by sending a Registration Revocation message to the FA providing the care-of address for the UE. The FA shall process the Registration Revocation message as described in RFC 3543 and respond to the HA with a Registration Revocation Acknowledge message.

Following successful registration revocation, the FA may provide an indication to the UE that its mobility binding has been reset by appropriate setting of the Agent Advertisement sequence number as described in RFC 5944. The FA may also initiate other actions to terminate the mobility session through other means that are beyond the scope of this document.

5.3.3.2 UE-initiated deregistration p. 11

When the FA receives an RRQ with a Lifetime field set to 0 from the UE, the FA shall process it as specified in RFC 5944 and TS 29.279. The FA shall validate the Mobile-Foreign Authentication extension if present.

The FA shall relay the RRQ to the HA IP address found in the RRQ.

If the HA accepts the RRQ, the FA shall send an RRP to the UE as specified in RFC 5944. If the non-3GPP access specific procedures require a security association between the UE and FA, the FA shall also include the Mobile-Foreign Authentication extension within the RRQ as specified in RFC 5944. The FA shall set the authenticator and SPI fields of the Mobile-Foreign Authentication extension to the MN-FA key and associated MN-FA-SPI generated as described in TS 33.402.

In case of a return home event, the deregistration procedure occurs between the UE and the HA; as such, the FA is not involved.