Title:
Femto Stage 2 Call Flows
Abstract:
This contribution proposes a few stage 2 call flows to be included in
section 9 of X.P0059-100.
Source:
Jun Wang/Chandru Sundarraman/Anand Palanigounder
QUALCOMM Inc.
jwang/csundarr/apg@qualcomm.com
Date:
Oct 27, 2008
Recommendation:
Review and adopt it.
Notice
Contributors grant a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other copyrightable
material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell
in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include portions of the
contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such
contributions or the resulting Organizational Partner’s standards publication. Contributors are also willing to grant licenses
under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of
practicing an Organizational Partner’s standard which incorporates this contribution.
This document has been prepared by the contributors to assist the development of specifications by 3GPP2. It is proposed to the
Committee as a basis for discussion and is not to be construed as a binding proposal on the contributors. Contributors
specifically reserve the right to amend or modify the material contained herein and nothing herein shall be construed as
conferring or offering licenses or rights with respect to any intellectual property of the contributors other than provided in the
copyright statement above.
2
9.1 Femto Initialization Call Flow without Redirection
Figure 1 shows the initialization call flow for 1x FAP, HRPD FAP, or HRPD and 1x Hybrid
FAP unless noted in the step descriptions.
Public DNS
Server
FAP
1
S-FGW
DNS
Server
S-FMS
CSCF/MFIF
Femto Powers up and initiates
Neighborhood discovery;
Neighborhood discovery should be
completed prior to step 4
DNS Query (S-FGW)
2
3
Establish Tunnel
DNS Query (FMS)
4
5
TR-069: Auto-configuration with Serving FMS. FMS configures FAP with the femto identities
and provisions it with the serving CSCF and other network entities
1x RTT FAP connects to CSCF and performs IMS registration; CSCF registers FAP with MFIF
6
7
IS-801 Session to determine Femto Location
TR-069: Auto-configuration with Serving FMS. If not already
Configured, FMS configures FAP with location specific radio parameters
8
9
FAP is now configured and registered
with the operator’s network
FAP now is ready to serve MS/AT
Figure 1 femto Initialization Call Flow without Redirection
1.
FAP performs neighborhood discovery as specified in TSG-C document (C.S00xx). FAP
reads the system parameter messages of the strongest neighboring marco cell to obtain
the system information such as SID, NID, Subnet ID etc. FAP also observes the pilot
channels of other neighboring cells as specified in [C.S00xx]
2.
FAP performs FGW discovery through the public DNS server.
3.
FAP establishes IPsec tunnel with the FGW discovered in step 2. In this step, FAP
subscription authorization is also performed.
4.
FAP performs FMS discovery through established IPsec tunnel.
5.
FAP connects to FMS to perform FAP provisioning and configuration. FAP sends its
neighborhood information during the auto-configuration stage. FAP is configured with
MPC/
PDE
the femto parameters and identities as defined in TBD and the IP addresses of the
network elements as specified in TBD
6.
FAP performs IMS registration with the CSCF. CSCF performs third party registration of
FAP with the MFIF. This step only applies to 1x FAP or 1x/HRPD Hybrid FAP.
7.
If the location of FAP is not accurately known, the FAP establishes an IS-801 session
with the PDE as specified in [J-STD-036]. This step only applies to 1x FAP or 1x/HRPD
Hybrid FAP. Position location determination for HRPD only FAP is FFS.
8.
FAP reconnects to FMS with the accurate location information. If the FAP is not already
configured with the location specific radio parameters and other identities, FMS
completes the configuration of FAP.
9.
FAP has now completed the initialization procedure and is ready to serve the MS/AT.
4
9.2 Femto Initialization Call Flow with Redirection to serving system
Figure 2a shows the FAP initialization call flow with FMS redirection for 1x FAP, HRPD FAP, or HRPD and
1x Hybrid FAP unless noted in the step descriptions.
FAP
1
2
Local
DNS
D-FGW
DNS
Server
D-FMS
S-FGW
DNS
Server
FMS
CSCF / MFIF
DNS Query(DFGW)
Establish Tunnel
DNS Query(FMS)
3
TR-069: Auto-configuration of FAP by D-FMS:
FMS redirects FAP to serving FGW/FMS
4
Close Tunnel
5
6
Establish Tunnel
DNS Query (FMS)
7
8
TR-069: Auto-configuration of FAP by S-FMS: FMS provision FAP with femto identities and address of network entities
9
IMS registration of FAP with serving CSCF/ MFIF
10
11
12
IS-801 Session to determine Femto Location
TR-069: Auto-configuration of FAP by S-FMS: FMS provision FAP with location specific radio parameters
FAP is now configured and registered
with the network.FAP turn ON its
transmitter and is ready to serve MS
Figure 2a femto Initialization Call Flow with Redirection
Prior to step 4, FAP performs neighborhood discovery as specified in TSG-C document
(C.S00xx). FAP reads the system parameter messages of the strongest neighboring marco cell
to obtain the system information (such as SID, NID, BaseID, Subnet ID, etc.). FAP also
observes the pilot channel of other neighboring cells.
1.
After obtaining an IP address from the local/private network, FAP performs FGW
discovery through the public DNS server.
2.
FAP establishes IPsec tunnel with the FGW discovered in step 2. In this step, FAP
subscription authorization is also performed.
MPC/PDE
3.
FAP performs FMS discovery through established IPsec tunnel.
4.
D-FMS redirects FAP to S-FGW/S-FMS due to load balancing or due to FAP’s location
closer to S-FGW/S-FMS.
5.
FAP terminates the secure tunnel with the D-FGW
6.
FAP establishes IPsec tunnel with the S-FGW configured by D-FMS in step 4. In this
step, FAP subscription authorization is also performed.
7.
FAP performs S-FMS discovery through established IPsec tunnel.
8.
FAP connects to S-FMS to perform FAP auto-configuration. FAP sends its neighborhood
information [obtained during Neighborhood Discovery] during this auto-configuration
stage. FAP is configured with the femto parameters and identities as specified in TBD
and the IP addresses of the network elements as specified in TBD
9.
FAP performs IMS registration with the CSCF. CSCF performs third party registration of
FAP with the MFIF. This step only applies to 1x FAP or HRPD/1x Hybrid FAP.
10. If the location of FAP is not accurately known, the FAP should establish an IS-801
session with the PDE as specified in [J-STD-036]. This step only applies to 1x FAP or
1x/HRPD Hybrid FAP. Position location determination for HRPD only FAP is FFS.
11. FAP should reconnect to FMS with the accurate location information. If the FAP is not
already configured with the location specific radio parameters and other identities, FMS
completes the configuration of FAP
12. FAP has now completed the initialization procedure and is ready to serve the MS
6
Figure 2b shows the FAP initialization call flow where FAP is unable to communicate its rough location with
FMS redirection for 1x FAP, HRPD FAP, or HRPD and 1x Hybrid FAP unless noted in the step descriptions.
FAP
1
2
Local
DNS
D-FGW
DNS
Server
D-FMS
S-FGW
DNS
Server
S-FMS
CSCF / MFIF
DNS Query(DFGW)
Establish Tunnel
DNS Query(FMS)
3
TR-069: Auto Configuration by default FMS
(without Neighborhood Information)
4
5
IMS registration with default CSCF/ MFIF
IS 801 Session with MPC/PDE to determine Femto Location
6
TR-069: Auto Configuration with default FMS
and redirection to serving FGW/FMS
7
Close Tunnel
8
9
Establish Tunnel
DNS Query (FMS)
10
11
TR-069: Auto configuration with Serving FMS
12
13
IMS registration with serving CSCF/ MFIF
FAP is configured and registered with
network. FAP turns ON its 1x
transmitter and ready to serve MS
Figure 2b femto Initialization Call Flow with location determination and Redirection
MPC/ PDE
Prior to step 4, FAP performs neighborhood discovery as specified in TSG-C document
(C.S00xx). FAP attempts to read the system parameter messages of the strongest neighboring
marco cell to obtain the system information (such as SID, NID, BaseID, Subnet ID, etc.). FAP
is in poor coverage and unable to read the Macro system overhead messages and may not
have accurate GPS location information.
1.
After obtaining an IP address from the local/private network, FAP performs FGW
discovery through the public DNS server.
2.
FAP establishes IPsec tunnel with the FGW discovered in step 2. In this step, FAP
subscription authorization is also performed.
3.
FAP performs FMS discovery through established IPsec tunnel.
4.
FAP connects to FMS. D-FMS configures FAP with default FAP specific parameters and
identities as specified in [TBD] and the IP addresses of network entities [CSCF, etc..] as
specified in [TBD].
5.
FAP performs IMS registration with the default CSCF. Default CSCF performs third
party registration of FAP with the MFIF [See X.S0059-200]. This step only applies to 1x
FAP or 1x/HRPD Hybrid FAP.
6.
Since the location of FAP is not accurately known, the FAP establishes an IS-801 session
with the PDE as specified in [J-STD-036]. FAP obtains its location information. This
step only applies to 1x FAP or 1x/HRPD Hybrid FAP. Position location determination for
HRPD only FAP is FFS.
7.
FAP reconnects to D-FMS with its accurate location information. If the FMS determines
that the FAP needs to be served by a different FGW/FMS/CSCF/MFIF, it redirects the
FAP to serving system
8.
FAP terminates the secure tunnel with the D-FGW
9.
FAP establishes IPsec tunnel with the S-FGW configured by D-FMS in step 7. In this
step, FAP subscription authorization is also performed.
10. FAP performs S-FMS discovery through established IPsec tunnel.
11. FAP connects to S-FMS to perform FAP auto-configuration. FAP sends its accurate
location information during this auto-configuration phase. FAP is configured with the
femto parameters and identities as specified in TBD and the IP addresses of the network
elements as specified in TBD
12. FAP performs IMS registration with the CSCF. CSCF performs third party registration of
FAP with the MFIF. This step only applies to 1x FAP or 1x/HRPD Hybrid FAP.
13. FAP has now completed the initialization procedure and is ready to serve the MS/AT.
8
9.3 FGW Discovery
Figure 3 shows FGW Discovery.
AT
Public
DNS Server
FAP
1. FAP forms FQDN
of FGW
2. DNS Query (FQDN)
3. DNS Answer (FGW’s IP Address)
Figure 3. FGW Discovery
1.
The FAP generates the FQDN for the FGW. The constructed FQDN construction should
be in the format of TBD (“<HRPD-subnet>.FGW.<domain-name>” or “FGW.<domainname>”), where domain name is preconfigured in the FAP.
2.
The FAP sends a DNS query to the DNS Server including the FQDN.
3.
The DNS server responds with a DNS answer including the FGW’s IP address.
9.4 FAP-FGW IPsec Tunnel Establishment
Figure 4 shows FAP-FGW IPsec tunnel establishment.
FAP
Femto
AAA
FGW
1. Pre-configured SeGW Server
cert and trusted FAP device CA
certs (for FAP auth)
1. Pre-configure FAP device
cert & (optionally) trusted server
CA certs (for SeGW auth)
2. IKE_SA_INIT Request (HDR, SA, KE, Ni)
3.IKE_SA_INIT Response (HDR, SA, KE, Nr, CERTREQ)
4. IKE_AUTH Request (HDR, SK{IDi(FEID), CERT(FEID),
CERTREQ, AUTH, SA, TSi, TSr})
5. Verify FAP
Cert & AUTH signature; verify
IDi matches cert identity
8. IKE_AUTH Response (HDR, SK{IDr(FQDNofFGW),
CERT(SeGW), AUTH})
6. AAA Request (FEID)
7. AAA Response
(Authorization info)
9. Verify SeGW cert & AUTH
signature; verify Discovered GW ID
(FQDN) matches the identity in the
server cert (e.g.
dNSName.SubjectAltName)
IKE_SA and the first CHILD_SA is established
10.CREATE_CHILD_SA Request (HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]})
11. CREAT_CHILD_SA Response (HDR, SK {SA, Nr, [KEr], [TSi,
TSr]})
IPSec Tunnel is Established with 1st Child SA and 2nd
Child SA
Figure 4. IPsec Tunnel Establishment
1.
FAP is assigned a device certificate during it’s manufacturing. The FAP device certificate is signed by
a Certificate Authority (device certificate CA) trusted by the cdma2000 operator. The private key for
the certificate is stored securely at the FAP. Similarly, the FGW is assigned a server certificate. The
private key of the FGW server certificate is stored securely at the FGW. The FGW is also configured
with list of the root certificates corresponding to the trusted device certificate CAs. The FAP may also
be configured with the list of root CA certificates corresponding to the server certificates that the FAP
will accept for the FGW.
2.
The FAP initiates the IKEv2 exchange with the FGW, known as IKE_SA_INIT exchange by issuing a
IKE_SA_INIT Request to negotiate cryptographic algorithms, exchange nonces and perform a DiffieHellman exchange with the FGW. In addition, using the NAT Traversal procedures outlined in section
2.23 of Error! Reference source not found., the initiator includes NAT_DETECTION_SOURCE_IP
and NAT_DETECTION_DESTINATION_IP payloads to negotiate support for UDP encapsulation.
3.
The FGW responds with IKE_SA_INITI Response by choosing a cryptographic suite from the
initiator's offered choices, completing the Diffie-Hellman and nonce exchange with the FAP. In
addition, the FGW includes the list of FAP CA certificates that it will accept in it’s CERTREQ payload.
For successful FAP authentication, the CERTREQ payload has to contain at least one CA certificate
that is in the trust chain of the FAP device certificate. At this point in the negotiation, IKE_SA_INIT
exchange is complete and all but the headers of all the messages that follow are encrypted and integrity
protected.
10
4.
FAP initiates the IKE_AUTH exchange with the FGW by setting the IDi payload to FEID, CERT
payload set to the FAP device certificate corresponding to the FEID and the AUTH payload containing
the signature of the previous IKE_SA_INIT Request message (in step 3) generated using the private
key of the FAP device certificate. The authentication algorithm used to generate AUTH payload is
also included in the AUTH payload. The FAP also includes the CERTREQ payload contains the list of
CA certificates for FGW (server) authentication. . For successful FGW authentication, the CERTREQ
payload has to contain at least one CA certificate that is in the trust chain of the FGW server certificate.
5.
Using the CA certificate corresponding to the FAP device certificate, the FGW first verifies that the
FAP device certificate in the CERT payload has not been modified and the identity included in the IDi
corresponds to the identity in the FAP device certificate. If the verification is successful, using the
public key of FAP device certificate, the FGW generates the expected AUTH payload and compares it
with the received AUTH payload. If they match, then the authentication of the FAP is successful.
Otherwise, the FGW sends IKEv2 Notification message indicating authentication failure.
6.
If the network policy requires femto subscription authorization, the FGW contacts the Femto AAA to
verify that the FAP identified by FEID is authorized to provide service.
7.
Femto AAA responds with authorization result. If the authorization is not successful, the FGW sends
IKEv2 Notification message indicating authorization failure. Otherwise, the FGW proceeds with server
authentication.
8.
FGW responds with the IKE_AUTH Response by setting the IDr payload to the FQDN of the FGW,
CERT payload set to the FGW server certificate corresponding to the FQDN and the AUTH payload
containing the signature of the IKE_SA_INIT Response message (in step 5) generated using the
private key of the FGW server certificate. The authentication algorithm used to generate AUTH
payload is also included in the AUTH payload.
9. Using the CA certificate corresponding to the FGW server certificate, the FAP first verifies that the
FGW server certificate in the CERT payload has not been modified and the identity included in the IDi
corresponds to identify in the server certificate and contains the expected FGW value as discovered
during the FGW discovery procedures. If the verification is successful, using the public key FAP
server certificate, the FAP generates the expected AUTH payload and compares it with the received
AUTH payload. If they match, then the FGW (server) authentication is successful. This completes the
IKE_AUTH exchange. An IPSec SA with first CHILD_SA has been established between the FAP and
the FGW. The first CHILD_SA is used for best effort traffic, Tunnel management (Fx3), FAP
Configuration messages.
10. FAP sends CREATE_CHILD_SA request for setting up 2nd CHILD_SA.
11. FGW responds with CREATE_CHILD_SA Response. The 2nd CHILD_SA is used for SIP Signaling
and (HRPD) A11 Signaling and/or 1x VoIP and HRPD (A10) VoIP bearer.