Requirements for Fixed Mobile Convergence
draft-schott-fmc-requirements-02

Abstract

Fixed-mobile convergence encompasses a variety of use cases that include situations in which a wireless device travels between a point of attachment in a mobile network (such as a cellular base station) and another point of attachment anchored in a fixed network such as a WiFi hotspot. Convergence then means enabling an end-user to access services or retrieve content whatever the network access conditions (e.g., fixed or mobile access infrastructure), and whether the end-user is in motion or not. This document discusses the issues related to convergence and elaborates a set of requirements.

The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.

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."

This Internet-Draft will expire on January 11, 2013.

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.

Table of Contents

• 1. Introduction
• 2. Caution
• 3. Terminology
• 4. Requirements for MN Identification behind a CPE with NAT
• 4.1. Recommendations for MN Identification behind NAT
• 5. Requirements for Access Selection
• 6. Requirements for MN Mobility in Fixed Broadband Network
• 7. Requirements for Streaming
• 7.1. Personalization of Video Streaming Service
• 7.1.1. Discussion
• 7.2. Recommendations for Streaming
• 8. Security Considerations
• 9. IANA considerations
• 10. Acknowledgments
• 11. References
• 11.1. Normative References
• 11.2. Informative references
• Appendix A. Requirements for Content Adaptation
• Appendix A.1. Recommendations for Content Adaptation
• Authors' Addresses

1. Introduction

With network heterogeneity and huge demand of multimedia and audio-visual services and applications as a given, users' satisfaction is the aim of each service provider to reduce churn, promote new services and improve the ARPU (Average Revenue per User). The market is crowded. Many players provide Internet and entertainment services, which motivates new business models considering users' experience and considering roaming agreement between different operators. The new expectation for users' consumption style focuses on personalized and interactive usage. This allows users on one hand to share content across many devices and with other users, but on the other hand to access all content seamlessly at the touch of a button.

Consequently, Quality of Experience (QoE) has become a crucial determinant of the success or failure of the multimedia and audio-visual applications and services. QoE evaluates the users' perceived quality for the provided services and hence reflects the users' satisfaction. Regarding QoS, 3GPP has made architectural definitions as described in [TS23.203] and [TS29.212]. IETF has also described how QoS can be achieved over IP [RFC5865].

Various meanings can be ascribed to the term Fixed-Mobile Convergence. It is not the intention of this document to give a complete definition regarding business and technical aspects. Fixed-mobile convergence has recently been used to include various use cases in which a wireless device travels between a point of attachment in a mobile network (such as a cellular base station) and another point of attachment anchored in a fixed network such as a WiFi hotspot. Convergence refers to a perceived unification of the service level available to applications which is, to the extent feasible, independent of the nature of the underlying physical medium.

This document discusses issues raised by convergence and elaborates a set of requirements based on the problem statement and use cases as discussed in [I-D.xue-intarea-fmc-ps] and [I-D.sun-fmc-use-case]. These use cases have been under discussion in BBF [WT203] and 3GPP [cite]. The requirements discussed in this document are meant to help the IETF community to decide whether it should take part of the corresponding effort or not.

2. Caution

This document is a working tool to help assessing whether additional specification effort is required within IETF. Technical issues mentioned in this document are those which may require carrying out a specification effort within IETF.

The goal of this document to enable the analysis of technical issues and their requirements. These issues are relevant to particular use cases. The relevant use cases and associated requirements need thorough discussion.

Some of these technical issues are already covered by some existing IETF WGs. This document may provide motivation to advance such items in the standardization process.

3. 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 specified in [RFC2119].

The following additional terms are used in this document.

aggregation node

The access network node which connects CPE and UE devices to the Internet.

Codec

Compression/Decompression of multimedia data using either a hardware device or software.

CPE

Customer Premises Equipment, that is equipment found in the customer's physical location and provided by the network operator or service providers. DSL routers, Set-Top-Box (STB), and decoders are examples of CPE.

FMC

Fixed Mobile Convergence means enabling an end-user to access services or retrieve content whatever the network access conditions (e.g., fixed or mobile access infrastructure), and whether the end- user is in motion or not. This includes also access conditions with this own service profile although having access by a 3rd party.

host_id

an identifier for the wireless device, as described in [I-D.ietf-intarea-nat-reveal-analysis].

MN

"Mobile Node"; a device that can move from one wireless point of attachment to another. Other standard documents use different terminology for the same idea, for instance "UE" (for User Equipment), or AT (for Access Terminal).

NFC Identifier

Near Field Communications identifier.

Port set

a defined set of ports; in this document "port set" is used as an example of a host_id. Each host under the same external IP address is assigned a restricted port set. These port sets may then be advertised to remote servers. Port sets assigned to hosts may be static or dynamic.

SD

Standard Definition for video using a standard resolution.

HD

High Definition for video using an enhanced resolution.

4. Requirements for MN Identification behind a CPE with NAT

A popular deployment model in fixed networks is to provide a host with a single private IPv4 address at the home or small business LAN. Then, each host within the local network will be assigned a private IPv4 address; a NA(P)T function [RFC2663] is responsible for translating the private IPv4 address to the public IPv4 address assigned to the CPE (Customer Premises Equipment). Similar address translation features are also present now in mobile environment; as one example, CPE can be connected to mobile infrastructures.

IP address sharing is motivated by a number of different factors. And today, some servers use the source IPv4 address as an identifier to treat some incoming connections differently. Due to the use of NAT44 [RFC3022] and NAT64 [RFC6146]), that address will be shared. In particular, when a server receives packets from the same source address, because this address is shared, the server does not know which host is the sending host [RFC6269]. To be able to sort out the packets for each sending host, the server must have extra information in addition to the source IP address, to distinguish the sending host. This identifying information is called the "host_id".

As a general matter, the HOST_ID proposals do not seek to make hosts any more identifiable than they would be if they were using a public, non-shared IP address. However, depending on the solution proposal, the addition of host_id information may allow a device to be fingerprinted more easily than it otherwise would be. Should multiple solutions be combined that include different pieces of information in the host_id, fingerprinting may become even easier.

A set of solution candidates to mitigate some of the issues encountered when address sharing is used have been described and compared in [I-D.ietf-intarea-nat-reveal-analysis]. Among or aside this set of solutions, a mechanism will have to be recommended to supply host_id in the use cases described in Section 6 as well as in [I-D.xue-intarea-fmc-ps] and [I-D.sun-fmc-use-case].

A CPE can also be configured to offer a shared WiFi to any visiting host (also called Mobile Node, or simply MN) which does not belong to the subscriber (owning the CPE). A visiting MN uses that shared WiFi facility to access its services. Granting access to the service is usually conditioned by an access control phase (e.g., redirection to captive portal inviting the user to authenticate). Once access to the service is granted, the visiting MN can receive its services. Business model considerations for such service offerings are out of scope for this document.

Among various ways to offer shared WiFi service, operators may elect to re-use the NAT function embedded in the CPE to route the traffic issued from the visiting MN.

When the traffic of a visiting MN is multiplexed behind the same public IP address, upstream devices may be unable to distinguish the the traffic of the visiting MN from other traffic issued by devices belonging to the subscriber owning the CPE. This traffic identification may be required to enforce dedicated policies (e.g., Accounting, QoS policies, legal intercept, legal data storage, etc.). As a result, and in order for the operator to still support traffic management for this service, policy control/decision/enforcement MUST be based on the specific MN. In other words, traffic belonging to a visiting MN MUST be explicitly identified. The host_id jointly with the external IP address can be used for this purpose.

As one example, port sets can be used as a host-id. To illustrate, suppose the CPE assigns a private IPv4 address and a set of ports to a visiting MN. Then, the CPE can report the assigned port set to a aggregation node together with other information such as external IPv4 address, MAC address, etc. This information will be associated with the user-id provided during the authentication phase. The CPE then uses that port set for translating packets to and from that visiting MN. The set of ports (assigned by the CPE) and the external IP address (assigned to the CPE) are then sufficient to uniquely identify a MN. The reporting phase can be avoided if the CPE is pre-configured with a static list of port sets to be used for visiting MNs.

The use of port sets and some other methods to explicitly identify a visiting MN is discussed in [I-D.ietf-intarea-nat-reveal-analysis], but many other methods of identification are also possible. In order to ease the selection of the appropriate host-id solution for the FMC case, below are listed a set of requirements to be met:

• All traffic MUST be identifiable (including TCP, UDP and ICMP)
• The MN SHOULD be authenticated if it injects its own host-id
• Otherwise, the CPE SHOULD inject the host-id
• The CPE SHOULD strip any existing host-id
• The CPE and the aggregation node MUST support at least one common method to convey host-id.

4.1. Recommendations for MN Identification behind NAT

We recommend dedicated efforts to specify a mechanism to supply host-id for MNs behind CPE and NAT.

A solution analysis document for existing solution approaches would help.

5. Requirements for Access Selection

A multiple access environment requires appropriate choice of the access network (cellular, mobile, VPN,...) that the device is likely to be connected to. This selection may depend on various criteria such as user's preference, user profile, network capabilities and conditions, operator policies, application QoS requirements and so on. This access selection can happen when the wireless device is first connected to an access network, i.e. at bootstrapping phase, and when a new access network can be accessed to, for example as the device moves.

Relevant information should be collected for each access network type, including:

• Available Bandwidth
• Cost
• Latency
• other QoS information
• Operator Network Identification
• Network Protocol Family (IPv4 or IPv6).

Policy access SHOULD also be enabled.

A mapping between the network status and the service requirements should be specified to allow the MN to choose the network that best matches its service requirements.

It should be possible to manage the user's access in the presence of several candidate access networks (fixed and mobile).

6. Requirements for MN Mobility in Fixed Broadband Network

The following are the requirements for MN Mobility in Fixed Broadband Network:

• Handover between networks while the session is active according to the network status with the change in the MN attachment.
• Mechanisms and interfaces between operators or/and access networks SHOULD be deployed to manage the mobility of the traffic flows of their users.
• Mobility should be enabled whether or not coverage areas overlap.
• Differentiated Services for the mobile device (MN)
• Service guarantee when device is roaming or mobile
• Resiliency in the network nodes should be provided

7. Requirements for Streaming

Additional IETF specification may be desirable for personalization of streaming services, especially video.

7.1. Personalization of Video Streaming Service

7.1.1. Discussion

The proliferation of streaming services (e.g., video across multiple screens and connected devices) motivates video streaming service personalization -- especially for users desiring richer Quality of Experience (QoE). Personalization of such services could allow streaming content delivery in a customized manner depending on each user, the device used, and the network status mainly through the following choices:

i) delivery network (fixed or mobile),

ii) local access network (WiFi, Femto, ADSL, .),

iii) delivery mode (unicast, multicast, delivering content from the one server or from caches, ..)

In this way, the streaming content could follow the user from place to place regardless of the access network type and of the mobile node (MN) characteristics.

This requires technical solutions to allow the selection of the appropriate interface to be used by the MN. The MN typically does not have any global view of the congestion status of the network. Moreover, in many cases the owner of the device might attempt to gain the highest level of service (regardless of the cost of network use by the operator). Service levels need to be controlled by the network and/or the service domains, not the MN. Likewise, the ability of premium clients to access more QoS resources (e.g. more bandwidth) further supports the design guideline enabling network choices to be decided by the operator.

In many cases, the service level controls required by the network operator require traffic monitoring at the aggregation node. This may require further coordination between the aggregation node and the CPE in order for the aggregation node to have the proper policy information available.

To be able to select the appropriate network and adapt the content according to the network status there is a need to obtain information about the network status and its variation in a dynamic manner also during the session. For example, a session that started with HD content could change to SD if the network conditions degrades. The current adaptive streaming solutions (as the HAS: HTTP Adaptive Streaming) mainly count on the MN for selecting the suitable content.

However, if content adaptation happens at the content source (in contrast to HTTP adaptive streaming techniques currently existing, the source would only send the appropriate content for each client and save network resources. For example, H.264/AVC video is encoded into 2 Mbps for SD and 6Mbps for HD. A mapping between the network status and the service requirements is also needed, where the service requirements are mainly exhibited by the content source (owned by the Content provider or the service provider). Content adaptation directives could also be extracted from the content Metadata.

Personalization of streaming imposes the following requirements:

• Each user connection MUST be identified through identifying each MN in a separate manner and distinguishing the MN and the CPE identification. The MN identification could be simply an NFC identifier, MAC identifier, ... which is then administratively associated with more information reflecting the MN characteristics.
• Monitoring mechanisms MUST exist allowing the collection of QoS information for each access network type.
• Service layer monitoring (for instance through MPEG2 layer monitor for video content) SHOULD exist to choose the network best matching the service requirements.
• The switch from one network to another MUST maintain the session according to the network status with the change in the MN attachment.
• Mechanisms and interfaces between operators SHOULD be deployed to control the mobility of traffic flows of their users.

7.2. Recommendations for Streaming

The IETF SHOULD dedicate efforts to consider several issues related to the MN and also to the network status as follows:

1. Each MN needs to be identified and the MN identity needs to be updated during the session each time a new terminal is used. The characteristics of each MN being used needs to be known also (e.g. supported resolution, screen size, available network connectivity "WiFi, 3G, .." and the cost of using each type of available networks).
2. Information about is needed for each of the network parameters as detailed in Section 5,
3. A mapping between the network status and the service requirements needs to exist to enable selection of the network that best matches the service requirements.

8. Security Considerations

This document focuses on FMC requirements and the interworking of "WiFi, 3G, etc..." and should not give rise to any new security vulnerabilities beyond those described in IPSec [RFC4301], TLS [RFC5246] or SRTP [RFC3711]. Nevertheless an open network architecture aimed at fulfilling the requirements listed in this document may give rise to security issues not yet identified.

9. IANA considerations

None.

10. Acknowledgments

Contributions, comments, discussions, and remarks provided by David Binet, Mohamed Boucadair, Christian Jacquenet, Daniel Park, and Pierrick Seite are gratefully acknowledged.

11. References

11.1. Normative References

11.2. Informative references

Appendix A. Requirements for Content Adaptation

In this case, adaptation of content format (HD/SD, codec, ...) SHOULD be possible when delivering the same content (e.g. video streaming) regardless of the access network type and of the mobile node (MN) characteristics.

Appendix A.1. Recommendations for Content Adaptation

To be able to meet above high level requirement, the content adaptation function needs to:

1. identify the user connection by identifying each MN in a separate manner. The MN identity MUST be updated during the session each time a new terminal is used. The characteristics of each MN being used needs to be known also (e.g. supported resolution, screen size, available network connectivity "WiFi, 3G, .." and the cost of using each type of available network).
2. distinguishing the MN and the CPE identification (MOTIVATION?).
3. rely on service layer monitoring (for instance through MPEG2 layer monitor for video content) SHOULD exist to choose the network best matching the service requirements.

Authors' Addresses