Use Cases and Requirements in Fixed Mobile Convergence
draft-sun-fmc-use-case-00

FMC Working Group                                                 C. Xie
Internet-Draft                                                    Q. Sun
Intended status: Informational                             China Telecom
Expires: January 10, 2013                                   July 9, 2012

         Use Cases and Requirements in Fixed Mobile Convergence
                       draft-sun-fmc-use-case-00

Abstract

   This document provides a brief review of use cases in FMC (Fixed
   Mobile Convergence) architecture from operational point of view.  It
   also provides technical requirements and problems might be taken up
   in IETF.  It is intended to be complementary to the existing problem
   statement and requirements documents.

Requirements Language

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

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 10, 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

Xie & Sun               Expires January 10, 2013                [Page 1]
Internet-Draft                FMC use case                     July 2012

   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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Use case 1: Unified User Identification . . . . . . . . . . . . 3
   3.  Use case 2: Unified QoS provisioning capability . . . . . . . . 4
   4.  Use case 3: Seamless handover for VPDN tunnel . . . . . . . . . 5
   5.  Use case 4: Mobility  . . . . . . . . . . . . . . . . . . . . . 5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7

Xie & Sun               Expires January 10, 2013                [Page 2]
Internet-Draft                FMC use case                     July 2012

1.  Introduction

   In the FMC (Fixed Mobile Convergence) network, the major FMC aspects
   include the converged business and service, converged network and
   infrastructure, and converged user management and terminals.

   The fundamental principle of FMC all starts from the customer.  With
   a multitude of devices to fit different personal preference, multi
   heterogeneous networks including fixed, 3GPP, WiFi, etc., and
   different business models in practice, people are getting more and
   more confused on how to make the decision to choose their id for
   service, access network, etc.

   The customer needs a life without barriers.  The converged business
   will provide the customer with a uniform policy and user experience.
   It can be seamlessly and intuitively accessible across all devices
   and all networks.  The converged network and infrastructure will
   reduce the CAPEX and OPEX for operators, and incur minimal additional
   costs with the ever-changing business model.  The converged user
   management and terminals will offer a more simple and convenient user
   experience, which will deliver broadband connectivity and
   standardized multimedia services to a wide range of devices,
   including media servers, video cameras, portable media players, PCs
   and mobile phones.

   While BBF and 3GPP has done a lot of work on architecture model,
   interface definition, etc., protocol standardization work should
   still be undertaken in IETF which is acceptable to all parties and
   cultivates a common ecosystem based on Internet protocol
   architecture.

   The purpose of this document is to provide an overview of use cases
   in FMC, together with some technical requirements and problems might
   be taken up in IETF process.  Some issues have been taken by some
   existing WGs in IETF, and some can be applied but not specific to FMC
   scenario.  Our purpose can be regarded as a motivation to encouraging
   those working items to be standardized in IETF.

2.  Use case 1: Unified User Identification

   Consider a device of the subscriber accessing a network has to be
   authorised and authenticated as well as to assure reliability of the
   service,the device must be able to identified and recognized as the
   first step.  That means that the identity of the device must be
   transferred and acknowledged in the network.  Additionaly, the
   identifier for the device must be cooperated with each other between
   the multiple different access technologies in order to maintian the

Xie & Sun               Expires January 10, 2013                [Page 3]
Internet-Draft                FMC use case                     July 2012

   device management and uniform policy rule.

   In real network,ISP assign a subscriber-id the subscriber always.
   One subscriber may have multiple devices, including PC, mobile
   phones, ipad, etc., and may seamlessly cross multiple heterogeneous
   networks.  The subscriber can not only use this subscriber-id to
   access the network, but also use this subcriber-id to connect the
   same service applications (operator's service or third-party service)
   without additional appliance.  The devices of the same subscriber
   should be managed in a group.  This group could be identified by a
   identification.With this unified identication, the customer can log
   in different application systems with a single access control.
   Besides, operators and Content providers can also apply the unified
   access policy, accounting policy, etc., to the customer for the
   specific set of devices.

   Potencial Technical Issues:

   The Device Identifier is used to indicate each individual devices for
   the device.  Currently, IP address can be regarded as a device
   Identifier from the network layer.  However, these identifiers are
   difficult to be kept consistently with NAT/CGNs(Carrier Grade Network
   Address Translation) along the path.  As a result, addional
   techniques (e.g.  Host_ID, ID/Locator split, Device ID mapping to the
   network information,etc.)should be introduced to guarantee that a
   unique device Identifier will not be modified heterogeneous network
   environment.

   In addition, the different device for the same subscriber should be
   managed in a uniform rule.  SO the group identifier for the devices
   should be introduced.  Because it is the basis of many other
   techniques in FMC.  It should be used for unified subscriber
   management, policy control, single sign-on for applications, etc.

3.  Use case 2: Unified QoS provisioning capability

   Consider a customer was firstly watching TV with a smart phone on his
   way home, and the video stream is smooth.  When he arrives home, he
   switches the same TV channel to the television screen and keep
   watching.  This user experience should not decrease due to the
   handover between different devices, the QoS feature should remain
   consistent with customers' profile all the time.  In this situation,
   different devices will have this special requirement on display
   resolution, codec, etc.  And different networks will also have
   alternative ways to achieve these requirements.

   Moreover, content providers may provide differentiated service for

Xie & Sun               Expires January 10, 2013                [Page 4]
Internet-Draft                FMC use case                     July 2012

   subscribers.  When a customer roams from one network to another, or
   from one device or another, the user QoS priority should still be
   treated uniformly in Content Provider/ Service Provider (CP/SP),
   including bandwidth guarantee, Content Distribution Network (CDN)
   policy, etc.

   Potential Technical Issues:

   1.  Device feature identification: In this situation, not only does
       the device Identifier should be distinguished, but also the
       characteristics of different devices should be retrieved in the
       CP/SP network, i.e. the fixed network to take further operations.

   2.  QoS mapping: Unified user experience can only be achieved when
       heterogeneous networks interpret QoS parameters uniformly.

   3.  User identification: CP/SP should support to identify the
       subscribers across different devices and heterogenous network.

4.  Use case 3: Seamless handover for VPDN tunnel

   A virtual private dial-up network (VPDN) is a network that extends
   remote access to a private network using a shared infrastructure,
   VPDN allows individual users to connect to a remote network such as
   roaming sales people connecting to their company's intranet.  VPDNs
   use Layer 2 tunnel technologies (L2F, L2TP, and PPTP) to extend the
   Layer 2 and higher parts of the network connection from a remote user
   across an ISP network to a private network.  Sometimes, in order to
   ensure the confidentiality of the data sent to an remote user, IPsec
   is used to setup a secure tunnel from the VPDN Client to a central
   router.  However, when the user roams from one access point to
   another one,the network needs to provide a seamless remote access
   during handover.

   Potential Technical Issues:

   The issues that should be tackled in this case include device feature
   identification, seamless handover between different secure
   tunnels,Qos mapping, etc.  Currently, a possible solution is Mobike
   [RFC4555], which allows the IP addresses of the tunnel endpoints in
   IPsec tunnel mode to change.  However, other kinds of VPDN should
   also be solved in seamless handover case.

5.  Use case 4: Mobility

   Mobility is one of the most important items which should be

Xie & Sun               Expires January 10, 2013                [Page 5]
Internet-Draft                FMC use case                     July 2012

   considered in FMC work.  We introduce two mobility usecases here, one
   is mobility between different access technologies (WiFi and 3GPP),
   and the other is mobility in WiFi scenario, such as between APs.

   Customer service should be guaranteed during the switch between one
   access network to another.  For example, customer's call or video
   service shouldn't be interrupted when moving from 3GPP access to WiFi
   access techonology.  Even more we can see all the services depends on
   the substantive of customer's profile.  It is important to confirm
   the device identification binding or updated accordingly for the same
   device which is moving.

   Additionally, WiFi is one of the most important access technology for
   operators, it is possible that customer is playing video in the bus
   via WiFi.  The mobility between AP and 3GPP access, and APs,and in AP
   overlap area must be considered.  Even more, wherever the device is
   accessing to the service via WiFi, such as at home or in the hotspot,
   or even roaming to another WiFi operator's network, the QoS and
   service experience shoulud be uniform.

   Potential Technical Issues:

   1.  In order to provide uniform policy control, the device
       identification should be uniform or transferred during the device
       mobility.  This is the specical requirement for UE identifier.

   2.  When the service application roams from one device to another deivce of
       a subscriber, the uniform QoS and service experience should be
       guaranteed, even between different access networks.  Based on
       this requirement, PMIP and MIP can not achieve the QoS uniform
       during mobility.  Additional mechanism is needed.

   3.  In the scenario of WiFi, the service QoS and experience between
       different APs should be guanrantted during device mobility.  In
       this case, the WiFi connection status and the subscriber
       information should be tracked during mobility.

6.  IANA Considerations

7.  Security Considerations

   TBD

Xie & Sun               Expires January 10, 2013                [Page 6]
Internet-Draft                FMC use case                     July 2012

8.  Acknowledgements

   TBD

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, June 2006.

Authors' Addresses

   Chongfeng Xie
   China Telecom
   Room 708, No.118, Xizhimennei Street
   Beijing  100084
   P.R. China

   Email: xiechf@ctbri.com.cn

   Qiong Sun
   China Telecom
   Room 708, No.118, Xizhimennei Street
   Beijing  100084
   P.R. China

   Email: sunqiong@ctbri.com.cn

Xie & Sun               Expires January 10, 2013                [Page 7]