One document matched: draft-xue-fmc-ps-00.txt
Network Working Group L. Xue
Internet-Draft B. Sarikaya
Intended status: Informational Huawei
Expires: December 8, 2012 D. von Hugo
Telekom Innovation Laboratories
June 6, 2012
Problem Statement for Fixed Mobile Convergence
draft-xue-fmc-ps-00.txt
Abstract
The purpose of this document is to analyze the issues that have
arisen so far and to propose several use cases for the Fixed Mobile
Convergence. The term Fixed Mobile Convergence spans several
scenarios from true integration of fixed and mobile terminals,
services, and network infrastructure on both technical and management
level down to pure interworking between fixed and mobile networks in
serving access for multi-interface terminals like today's
smartphones. In the interworking scenario, the mobile network passes
on the mobile subscribers policies to the fixed broadband network in
order to maintain the end-to-end service level agreement and to
support remote terminal and access network management. Explicitly,
the fixed broadband network must have partnership with the mobile
network in Fixed Mobile Convergence interworking scenario. This
document gives a brief overview of the assumed Fixed Mobile
Convergence architecture and related works and then introduces
several Intarea type of use cases based on the partnership in Fixed
Mobile Convergence architecture, such as User Equipment
identification, mobility consideration, such as mobility in Wi-Fi
network and Personalization of streaming type of considerations.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Xue, et al. Expires December 8, 2012 [Page 1]
Internet-Draft PS for FMC June 2012
This Internet-Draft will expire on December 8, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Xue, et al. Expires December 8, 2012 [Page 2]
Internet-Draft PS for FMC June 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Key issues in Fixed Mobile Converged Interworking . . . . . . 8
4.1. UE identification in fixed broadband network . . . . . . 8
4.1.1. UE Identification in Femto Access . . . . . . . . . . 11
4.2. UE Mobility in Fixed Broadband Network . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Xue, et al. Expires December 8, 2012 [Page 3]
Internet-Draft PS for FMC June 2012
1. Introduction
Growing availability of intelligent mobile devices and mature
networks of operators providing both reliable carrier grade
connectivity and affordable high bandwidth access offer to the
customer a nice climate of mobile broadband. With widespread
availability and easy usability of mobile broadband, mobile broadband
applications become more ubiquitous. Subscribers demand for various
service applications, especially Internet applications, such as
mobile Internet video, mobile Internet real-time communication, etc.
The subscribers requirements lay the foundation of mobile broadband.
On the other hand, simultaneously, the subscribers' services promote
the evolution of mobile broadband, which will impact the network
architecture. The flourishing mobile applications demand more and
more bandwidth offered by the operators. Even with wireless networks
becoming mature, such as 3G and LTE, the average bandwidth offered is
not comparable to data rates offered by fixed networks. With data
services rapidly increasing, the traditional cellular network
operating at a shared medium and thus being limited in transmission
rate often becomes the bottle-neck of mobile broadband. In addition
radio network technology generally requires high capital investment
and operational expenditures. Cellular network operators are facing
the challenge of increasing traffic demand at decreasing revenue and
have to provide means of more cost efficient access technology in a
highly competitive environment. The trend of offloading the traffic
to fixed broadband network is emerging. Mobile industry has
specified functionalities to offload the data traffic to the fixed
broadband (FBB) network, via WLAN or a Home (e)NodeB (HNB or eNodeB,
aka. Femtocell) [TR23.829], which could alleviate traffic pressure
on the mobile network. That is to say, today, operators are able to
employ mechanisms to manage the subscriber service over both the
mobile and the fixed broadband network. We can say, FMC is emerging
on the basis of subscribers and operators requirements.
Fixed Mobile Convergence is a technology trend which aims to provide
the subscribers access to services regardless of the access network
type they are connecting to and provide the operators with the
flexibility to ensure transparency of services to the end user. For
a mobile subscriber to access services over both mobile and fixed
broadband networks seamlessly, additionally, the subscriber's end-to-
end service level agreement (SLA) must be maintained. This is
achieved by interworking the control planes of the fixed broadband
network and the mobile network.
In the FMC interworking scenario addressed here, the fixed broadband
network must partner with the mobile network to perform
authorisation, authentication, and accounting (AAA) and acquire the
Xue, et al. Expires December 8, 2012 [Page 4]
Internet-Draft PS for FMC June 2012
policies for the mobile subscriber. Please note, a single converged
control plane, used for both the fixed broadband and the mobile
network, may be used in a truely converged, i.e. integrated
convergence scenario. This document only focuses on the interworking
scenario in this version. The convergence scenario is for further
study.
Figure 1 shows the assumed reference architecture of Fixed Mobile
Convergence Interworking for a Mobile (3GPP) Network and a fixed non-
3GPP access network as proposed by 3GPP and BroadBand Forum (BBF) as
an example in document [WT203].
Xue, et al. Expires December 8, 2012 [Page 5]
Internet-Draft PS for FMC June 2012
+---------------------------------------+
| Mobile Network |
| ---- |
| +------+ / \|
| +----+ PCRF | |Operator|
| | +---+--+ | Service|
| | | \ /|
| | | --+- |
+------+ +------+ | +------+ +---+--+ | | |
| UE | | eNB +-----+ SGW +---+ PGW +-----|---------+----------+
+------+ +------+ | +------+ +--+---+---+ | +------+| |
| +--+---+ +-|-----+M AAA || --+-
| | ePDG +---+ | +---+--+| / \
+------------+------+-----|---------|---+ |Internet
| | | | Service
+---------------|---------|---------|---+ \ /
| Fixed Network | +---+--+ +---+--+| --+-
| | +---+ BPCF | |F AAA || |
| +--+-+-+ +------+ +---+--+| |
+------+ | | BNG +---------------+ | |
| Femto+-----------+ +--+-+-+ | |
+------+ | | | +----------------------------+
+------+ | | +--+---+ |
| UE | | +----+ AN | |
+------+ +------+ | +--+---+ |
|WiFiAP|-------------------+ |
| CPE | | |
+------+ | |
+---------------------------------------+
Legend:
M AAA Authentication Authorization Accounting in Mobile Network
F AAA Authentication Authorization Accounting in Fixed Network
AN Access Node
BPCF Broadband Policy Control Function
BNG Broadband Network Gateway
ePDG evolved Packet Data Gateway
PCRF Policy Charging Rule Function
PGW Packet Data Network Gateway
SGW Serving Gateway
UE User Equipment
Figure 1: Reference Architecture of Fixed Mobile Convergence
The policy and charging control (PCC) system is an important element
in FMC architecture. PCC system of FMC consists of policy decision
point (PCRF in the mobile network and BPCF in the fixed broadband
network) and the policy enforcement point (PGW and BNG,
respectively), shown in Figure 1. PCC should support for controlling
Xue, et al. Expires December 8, 2012 [Page 6]
Internet-Draft PS for FMC June 2012
the QoS (e.g., QoS class and bit rates) authorized for service, and
IP flow based charging. In FMC interworking scenario, these services
can be divided into four types.
1. Service via macrocell wireless network
2. Service via WiFi/Femtocell access routed back to 3GPP Evolved
Packet Core (EPC), where the fixed broadband network is used as
the access network,
* The service from a mobile UE is connected to WiFi or to
Femtocell Access Point (FAP) at the residential gateway (RG),
routed back to 3GPP Evolved Packet Core (EPC).
3. Services via WiFi access only fixed broadband routed
* The service from a mobile UE is connected to WiFi without
traversing the mobile network.
* In this scenario, the UE service may be guaranteed based on
subscriber's policy from the mobile network.
4. LIPA/SIPTO traffic
* Support of Local IP access (LIPA) and of Selected IP traffic
offload (SIPTO) for the Home (e)NodeB Subsystem and for the
macro layer network include a more integrated FMC scenario and
thus are for further study.
As for the services stated above, only the second and the third type
are related to FMC, where both the fixed broadband and the mobile
network are involved. The FMC architecture shall be capable to set
operator policies to support simultaneous access to these service.
In the network today, deploying FMC is a worthy way for operators to
satisfy subscriber's requirement and ease pressure from bandwidth.
In the following sections, we first describe the motivation and then
discuss the key issues that are at this time limited to the Intarea
and to FMC interworking scenario.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Xue, et al. Expires December 8, 2012 [Page 7]
Internet-Draft PS for FMC June 2012
3. Motivation
The motivation is to highlight and discuss the issues when
facilitating FMC. We systematically analyze the issues that have
been proposed so far and briefly assess the possible extensions which
could solve the problems. In the network architecture, we target and
limit the scope to the interworking architecture for FMC. The
convergence architecture is out of scope.
Regarding the traffic management and control requirements in FMC
interworking scenario, there are two essential issues from an IETF
Internet Area and fixed broadband network point of view, as follows.
1. UE identification in fixed broadband network
2. UE Mobility in fixed broadband network
In Section 4 below, we discuss the key issues and some problems based
on the FMC architecture. There are many standardization issues
related to FMC and protocol extension work needed are stated in this
document.
If these issues are fixed, the advantages brought out will be:
1. Optimize traffic management (per-UE granularity in the fixed
broadband network)
2. Enhance device management (via IP address synchronization between
fixed broadband network and mobile network)
3. Quick Responsiveness based on UE status
4. Key issues in Fixed Mobile Converged Interworking
This section provides some key issues related to FMC when deployed.
These issues, which motivate the FMC, must be resolved. It is
difficult to foresee the most suitable solutions to resolve these
issues now, but in any event, some possibilities need to be analysed
based on the scenarios. Mobile network solutions of these issues are
out of scope.
4.1. UE identification in fixed broadband network
A user accessing a network point of attachment has to be authorised
and authenticated by the network as well as vice versa to assure
reliability of service as well as proper exchange of accounting
information. That is the identity of the user and the AAA
Xue, et al. Expires December 8, 2012 [Page 8]
Internet-Draft PS for FMC June 2012
credentials have to be transferred and acknowledged. In addition a
unique identity has to be assigned to the customer and/or his
terminal, i.e. to maintain a session, a routable IP address has to be
provided. Detailed consideration of AAA issues is out of sccope of
this document.
Nowadays, a subscriber is always provided with a single private IPv4
address at their home or small business, which should reduce the
pressure on the available public IPv4 addresses which are now
exhausted. For instance, in the fixed broadband network, each host
within the local network will be assigned a private IPv4 address,
then NA(P)T function is responsible for translating the private IPv4
address to the public IPv4 address assigned to the CPE (Customer
Premises Equipment) by operators, and vice versa.
As a result of maintaining growth of IPv4 service, private addressing
plan will require address sharing, which will cause issues for
operators, such as traffic management, QoS enforcement, etc. in the
FMC scenarios, where the policy control must be based on the
fundamental concept of per-UE granularity. Note that ultimately,
deploying IPv6 is the only perennial way to ease pressure on the
public IPv4 address without the need for address sharing mechanisms
that give rise to the issues identified herein. But in the interim,
however, IPv4 services are also very important for end-users, and
service providers, which can not be ignored.
The FMC architecture shall be capable to set operator policies to
support simultaneous access to mobile services and traffic offloading
to the fixed broadband network. Accordingly, regarding policy and
QoS interworking between the fixed broadband and mobile
architectures, we consider the following scenarios:
1. Mobile UE with mobile-routed traffic with NAT in RG
2. Mobile UE with offloaded traffic with NAT in RG
Issues will be introduced in the cases above because of address
sharing via NA(P)T. The important consideration is that today's PCC
(including QoS control and IP flow based charging) must be based on
the fundamental concept of IP Connectivity Access Network (IP-CAN) in
per-UE granularity. IP-CAN session [TS23.203] is the association
between a UE and an IP network. So in FMC network, it is assumed
that fixed broadband network could manage the traffic in per-UE
granularity.
Obviously, the fixed broadband network and mobile network must
support inter-operator subscribers policy exchange, this introduces a
major challenge on how to coordinate UE identification across the
Xue, et al. Expires December 8, 2012 [Page 9]
Internet-Draft PS for FMC June 2012
operators' domains so that the mobile network can inform the suitable
policy to the serving fixed broadband access network that its mobile
user equipment (UE) is attached to. So that the fixed broadband
network can provide the appropriate FMC interworking policy and
bearer control on UE's traffic.
There may be limitations with BNG implementations with respect to the
level of granularity (per-UE) of the enforcement. Take case 2 for an
example, a key problem is to identify offloaded traffic from a
special UE, i.e. UE identification substantively, behind the NA(P)T
embedded into RG, there is no longer a unique IP address per UE, in
addition, the UDP port behind NA(P)T is not bound to the special UE.
Another factor that contributes to UE identification is efficient
packet inspection. Operators expect the fixed broadband network
could be configured in such a way that the traffic subject to packet
inspection is routed via the Traffic Detection Function (TDF)
[TS29.212], otherwise, the traffic that is not subject to packet
inspection may bypass the TDF. This assumption only holds if it is
possible to identify individual UEs behind NA(P)T embedded into the
RG in fixed broadband network, shown in Figure 2. Issues may arise
if there is a NA(P)T in or beyond the RG, even a NA(P)T in or beyond
the BNG. As a result, additional mechanisms are needed to enable
this.
Xue, et al. Expires December 8, 2012 [Page 10]
Internet-Draft PS for FMC June 2012
+--------+
| |
+-------+ PCRF |
| | |
| +--------+
+--------+ +--------+ +--------+ +----+----+
| | | | | +-----+ |
| ------------------------------------------------------------------
| | | | | | | TDF | / \
| ******************************************************************
| | | +-------+ | | | Service
| | | | | | | \ /
| | | | | | | +--------+
| | | | | | +--------+ |
| ********---------**********--------************------------******* |
| UE | | CPE | | BNG +------------------+ PGW |
+--------+ +--------+ +--------+ +--------+
Legends:
--------- 3GPP UE User Plane Traffic Offloaded subject to packet inspection
********* 3GPP UE User Plane Traffic Offloaded not subject to packet inspection
*****---- 3GPP UE User Plane Traffic Home Routed
Figure 2: UE's Traffic Routed with TDF
As discussed before, there are many drivers for the identification of
the host or UE when an IP (v4 or v6) address is shared among several
users in the broadband network. They include efficient packet
inspection, QoS enforcement, charging. We can note that all these
functions in FMC depend on being able to identify UEs behind the
NA(P)T functionality .
There are several possibilities which provide solutions. There are
several possible IP, ICMP (both v4 and v6) or TCP/UDP protocol
extensions, discussed in [I-D.ietf-intarea-nat-reveal-analysis]. In
that document, TCP host identifier option is also discussed.
Additionally, there may be other possibilities, such as some other
new identifier to be defined as the host identifier to be passed by
the subscriber to a server such as BNG or TDF. It is difficult to
foresee which is the suitable solution, more work needs to be done.
4.1.1. UE Identification in Femto Access
Identification of UE behind a NA(P)T box manifests itself as a
subproblem if Femto Access points are used by the UEs instead of
Wi-Fi Access Points.
Xue, et al. Expires December 8, 2012 [Page 11]
Internet-Draft PS for FMC June 2012
Femtocells (FAPs), whose architecture is specified in the mobile
standards (e.g., 3GPP, Femto Forum, etc.), are an exemplary feature
of an FMC network. The access network to which Femtocells are
attached is the fixed broadband network. As mentioned before, in
order to achieve PCC, there is a need for the fixed broadband network
to have partnership with mobile network to maintain the service level
agreement (SLA). Here, the private IPv4 addressing plan in fixed
broadband network introduces the limitations. In today's generic FAP
architecture, it is difficult to guarantee a unique mapping, shown as
follows:
1. Determine the UE attached FAP's public IPv4 address together with
the translated port number of the UDP header of the encapsulated
IPsec tunnel between the FAP and the Security Gateway (SeGW)
which are assigned by the fixed broadband network. The FAP's
public IPv4 address is:
* used for identifying the location of the FAP,
* used for identifying the UE's traffic at the fixed broadband
network.
2. Determine the corresponding FAP's public IPv4 address's
association with the UE's inner-IPv4 address which is assigned by
the mobile network. The association is:
* used for identifying the mobile UE that is attached to the FAP
in order to allow the PCRF to retrieve the UE's policy to be
passed onto the BPCF at the fixed broadband network.
Due to the requirement for inter-operators subscribers policy
exchange, the private and public addressing which rely on NA(P)T,
must be coordinated cross the operators domains. Additionally, FAP
location must be identified for management. These major factors
drive the solutions in interworking architecture with Femtocell
scenario such as extending IKEv2 [RFC5996] with vendor specific
attributes, so that the overall service performance and the user
experience could be enhanced.
4.2. UE Mobility in Fixed Broadband Network
The users are the mobile subscribers in FMC. Note that all the
services depend on the substantive character of subscriber's
mobility. It is important for operators to capture the user device
when it is moving into or outside the network, even in WiFi access.
Besides, the application and service from the subscriber must be
guaranteed based on the policy of operators.
Xue, et al. Expires December 8, 2012 [Page 12]
Internet-Draft PS for FMC June 2012
In mobile network today, there are many mature solutions offered for
user's mobility already. Herein, only mobility in fixed access,
i.e., WiFi access, will be considered. For example, the user device
is attached to the home LAN (e.g., WiFi ) network, and establishes a
connection back to the subscriber's mobile service provider network
via the fixed broadband network. The mobile operator should
cooperate with the broadband access operator to deliver proper policy
for the service from UE.
The mobility considered in the fixed access is a little different.
In this section, we divide the mobility capability into two cases:
1. UE is moving into or outside the coverage area of WiFi AP
2. UE's WiFi access is dormant or not.
The following figure shows an example of the scenario where mobile
UEs are served in WiFi deployment over the fixed broadband network.
RG embeds WiFi AP and NA(P)T function. Each UE is provided with a
single private IPv4 address assigned within the local network.
NA(P)T in RG is responsible for translating the private IPv4 address
to the public IPv4 address assigned by the fixed operator.
Xue, et al. Expires December 8, 2012 [Page 13]
Internet-Draft PS for FMC June 2012
Policy for UE
identified by IP + Port
+-------------+| +------------------------+
| || | |
| || | |
| || | |
| +------+ || | +------+ +---------+ |
| | BPCF +---+V--+-+ PCRF +--+ MME | |
| +--+---+ | | +---+--+ +----+----+ |
+----+ | | | | | | |
|UE1 |Private IP1 | +--+---+ | | +---+--+ +----+----+ |
+----+ +---+ | | | | | | | | | |
| <----------+--+------+---+---+-> | | | |
|CPE| | | BNG | | | | ePDG +--+ SGW | |
+----+ | <-^--------+--+------+---+---+-> | | | |
|UE2 | +---+ | | | | | | | | | | |
+----+Private IP2 | | +------+ | | +------+ +----+----+ |
| | | | | |
| | | | | |
| | Fixed | | +----+----+ |
| | Broadband | | | | |
Public IP | Network | | | PGW | |
NA(P)T | | | | | |
+-------------+ | +----+----+ |
| Mobile | |
| Network | |
| | |
Legends: +----------------+-------+
--+-
<---> / \
<---> IPsec Tunnel |Internet|
| Service|
\ /
----
Figure 3: Mobility in the Fixed Broadband Network
As described previously, BPCF in fixed broadband network must have
partnership with PCRF in mobile network in order to maintain the
service level agreement (SLA). In order to allow the PCRF to
retrieve the UE's policy to be passed onto the BPCF in the fixed
broadband network, it is mainly concerned about the traffic and UE
identification binding used to achieve the actual traffic control.
The BPCF/BNG will perform the policy control based on the binding.
Based on the UE's mobility, issues will arise. For example, the PCRF
will retrieve the wrong policy to the BPCF, if the UE identification
can not be updated in time. For instance, there are two UEs, shown
Xue, et al. Expires December 8, 2012 [Page 14]
Internet-Draft PS for FMC June 2012
in Figure 3. UE1 and UE2 are assigned different private IP addresses
within the local network, IP1 and IP2 accordingly. After NAPT, BPCF/
BNG will be based on the public IPv4 address and the different UDP
port numbers assigned by NAPT to perform the admission control and
policy enforcement on the UE's traffic.
Since plenty of UEs may move into the coverage of WiFi AP, it is
possible that the same UDP port will be used for both UE1 and UE2 at
the different time period. For example, UE1 moved out of the WiFi
coverage and later the UE2 moved in. The same UDP port used by UE1
before is assigned to UE2 again. As mentioned, the identification
must be consistent between fixed broadband network and the mobile
network for policy exchange. So the UDP port used as part of UE
identification must be updated in time based on the status of UE,
otherwise the PCRF will confused about which policy is used.
Especially, there may be a requirement to binding the UDP port to a
special UE described in Section 4.1. The UDP ports must be cleared
if the UEs corresponding to prior port binding are out of coverage of
the WiFi AP. That is to say the configuration must be updated
regularly to satisfy that the WiFi AP can serve thousands of UEs.
Other solutions to solve the issue in Section 4.1 may also fix this
challenge introduced by the mobility of UE.
Possible solutions approaches include extending the Control And
Provisioning of Wireless Access Points (CAPWAP) architecture RFC 5415
[RFC5415]. Access Controllers using an extended protocol can be
charged to keep track of the mobility status of the UEs that are
connected to the fixed broadband network using IEEE 802.11 links.
5. IANA Considerations
This document makes no request to IANA.
6. Security Considerations
Serious concern of mobile operators towards FMC approaches has been
the customer access via networks not under control of the operator.
Operators would like to keep their own high security measures to
prevent various kinds of fraud or attack to the operators services
and network entities. Well known risks and vulnerabilities which are
common to any NA(P)T application are documented in the NAT
specification [RFC2663]. Any additional security considerations
arising from FMC are TBD.
Xue, et al. Expires December 8, 2012 [Page 15]
Internet-Draft PS for FMC June 2012
7. Acknowledgements
Many people provided comments that have been incorporated into this
document including Mohamed Boucadair, David Binet, Pierrick Seite and
Cameron Byrne.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And
Provisioning of Wireless Access Points (CAPWAP) Protocol
Specification", RFC 5415, March 2009.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269,
June 2011.
[TR23.829]
"3GPP TR23.829, Local IP Access and Selected IP Traffic
Offload (LIPA-SIPTO)", October 2010.
[TS23.203]
"3GPP TS23.203, Policy and Charging control architecture",
December 2011.
[TS29.212]
"3GPP TS29.212, Policy and Charging Control (PCC) over
Gx/Sd reference point", December 2011.
8.2. Informative References
[I-D.ietf-intarea-nat-reveal-analysis]
Boucadair, M., Touch, J., Levis, P., and R. Penno,
"Analysis of Solution Candidates to Reveal a Host
Identifier (HOST_ID) in Shared Address Deployments",
draft-ietf-intarea-nat-reveal-analysis-02 (work in
progress), April 2012.
[I-D.so-ipsecme-ikev2-cpext]
Xue, et al. Expires December 8, 2012 [Page 16]
Internet-Draft PS for FMC June 2012
So, T., "IKEv2 Configuration Payload Extension for Private
IPv4 Support for Fixed Mobile Convergence",
draft-so-ipsecme-ikev2-cpext-01 (work in progress),
February 2012.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental
Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264,
June 2011.
[TS24.302]
"3GPP TS24.302, Access to the 3GPP Evolved Packet Core
(EPC) via non-3GPP access networks", March 2012.
[TS24.312]
"3GPP TS24.312, Access Network Discovery and Selection
Function (ANDSF) Management Object (MO)", March 2012.
[WT146] "Broadband Forum Working Text WT-146, Subscriber
Sessions", June 2011.
[WT203] "Broadband Forum Working Text WT-203, Interworking between
Next Generation Fixed and 3GPP Wireless Access",
December 2011.
Authors' Addresses
Li Xue
Huawei
NO.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,
Beijing, HaiDian District 100095
China
Email: xueli@huawei.com
Behcet Sarikaya
Huawei
5340 Legacy Dr.
Plano, TX 75074
Email: sarikaya@ieee.org
Xue, et al. Expires December 8, 2012 [Page 17]
Internet-Draft PS for FMC June 2012
Dirk von Hugo
Telekom Innovation Laboratories
Deutsche-Telekom-Allee 7
D-64295 Darmstadt
Germany
Phone:
Email: Dirk.von-Hugo@telekom.de
Xue, et al. Expires December 8, 2012 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 02:34:15 |