Internet DRAFT - draft-sfc-sinha-5g-ims-dual-reg

draft-sfc-sinha-5g-ims-dual-reg



Service Function Chaining                              Sunil Kumar Sinha
Internet-Draft                              Infinite Computing Solutions
Intended status: Informational                            Amardeep Sinha
Expires: December 17, 2018                 Reliance Jio Infocomm Limited
                                                             Amit Mishra
                                                          Varsa Networks
                                                       Manish Srivastava
                                                      Commscope Networks
                                                           June 18, 2018


       5G IMS system supporting dual-Registration for Dual-Access
                   draft-sfc-sinha-5g-ims-dual-reg-00


Abstract

   This document attempts the case for new work that need to be 
   developed for 5G user to improve user reachability outlining the poor
   radio coverage issue with respect to voice and video services by IMS
   network. This document also outlines dual access capabilities of 5G
   user device and user is reachable on each access-type leading to
   faster user reachability.

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 https://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 December 17, 2018.

Copyright Notice

   Copyright (c) 2018 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
   (https://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.

sinha                   Expires December 17, 2018              [Page 1]

Internet-Draft      5G Dual Registration Dual Access           June 2018


Table of Contents:

   1. Introduction...................................................2
   2. Conventions and Terminology....................................2
   3. Problem Statement..............................................2
   4. 5G IMS system supporting dual-Registration for Dual-Access.....2
   5. Security Considerations........................................5
   6. IANA Considerations............................................5
      6.1 IANA Registration of the "dual" Option Tag ................5
   7. Privacy Considerations ........................................6
   8. Acknowledgements...............................................6
   9. References.....................................................6
      9.1 Normative References.......................................6
      9.2 Informative References.....................................6
   Authors' Addresses................................................6

1. Introduction

   5G system have been evolved to server 5G Users with dual access
   capability at same time. User access to network service for mo-data
   and mt-data for voice and video or data services via both access
   type is increased if user's registration state for a particular
   service is maintained on each access type independently. In this
   document, user access to voice and video service is discussed and
   proposal made to maintain user registration state for each access
   type of a user at P-CSCF.

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

3. Problem Statement

   With user registered for a service for only one access type at a
   time, then probability of user reachability at the time of service
   delivery leads to considerable amount of delay in UE hunting
   procedure.

   User registered on access type may happen that user goes
   out of network coverage at the time of serve being delivered.
   Hunting fails thereby trigger user hunting on another access type.

   A considerable amount of delay is incurred on this hunting procedure.
   This document outlines this problem by proposing a solution of 
   dual-registration in section-4.

4. 5G IMS system supporting dual-Registration for Dual-Access

   A simplified 5G-system architecture with dual access is show in
   Figure 1 below.

sinha                   Expires December 17, 2018              [Page 2]

Internet-Draft      5G Dual Registration Dual Access           June 2018


           +--------------------------------------------------------+
           |             +----------------------------+             |
           |             | +------------------+       |             |
           |             | |                  |       |             |
           |             | |                  |N8     |N15          |
           |             | |                  |       |             |
           | +------+    | | +------+  N13  +---+     |             |
           | | NSSF |--+ | | | AUSF |-------|UDM|     |             |
           | +------+  | | | +------+       +---+     |             |
           |           | | |     |            |       |             |
           |           | | |     |            |       |             |
         N3|        N22| | |     |N12      N10|     +---+  N5  +--+ |
           |           | | | +---+            |     |PCF|------|AF| |
           |           | | | |                |     +---+      +--+ |
           |           | | | |                |       |             |
        +-----+      +---------+           +-----+    |             |
        | RAN |------|   AMF   |-----------| SMF |----+             |
        +-----+  N2  +---------+    N11    +-----+   N7             |
           |             |                    |                     |
  +--+  Uu |             |                    |                     |
  |  |-----+             |N2                  |N4                   |
  |UE|                   |                    |                     |
  |  |-----+             |                    |                     |
  +--+  Y1 |  +----------+          +---------+                     |
           |  |                     |                               |
           |  |                     |                               |
        +--------+       N3      +-----+  N6  +-------------+       |
        |AP+N3IWF|---------------| UPF |------| Service N/W |       |
        +--------+               +-----+      +-------------+       |
                                    |                               |
                                    +-------------------------------+

      Figure 1: Simplified 5G-system Architecture for Multi access

   UE upon successful attached to 5G-core by either of access type, 
   3GPP or non-3GPP, received following details 

       - UE IP-address
       - IMS access IP-address (P-CSCF discovery)

   Since UE of 5G System is capable of dual access, implies UE can
   simultaneously have active connections with both 3GPP and non-3GPP
   access at same time.  This in turn implies UE is reachable via both
   access type at same time. 

   Let us consider a simple case where the 5G UE device having dual
   access capability gets powered-on and both Wifi and RAN network is
   available.

   - UE first get attached to RAN and send fresh Registration request to
     the IMS network. While sending sine Wifi attached procedure was not
     completed, hence Fresh REGISTRATION request via RAN access with
     have PANI header=E-UTRAN with no optional tag.

sinha                   Expires December 17, 2018              [Page 3]

Internet-Draft      5G Dual Registration Dual Access           June 2018


  - Upon successful REGISTRATION stores the UE registration data in the
    following format in Table :1.

  Table :1

   +------+------+-------+---------+----------------+------------------+
   | PANI | IMSI | IPsec | Call-ID | Register-Timer | P-Associated-URI |
   +------+------+-------+---------+----------------+------------------+

   - Upon successful Wifi attached procedure was successful, UE also
     triggers for FRESH REGISTER request to IMS network. Since RAN 
     access was active, hence UE MUST send this FRESH REGISTRATION with
     PANI header=wlan with option tag=dual, indicating dual
     registration.

   - The second registration request triggered via another access type,
     in this example wifi will be again Un-Protected Registration, i.e.
     different call-ID and different IPsec as shown in Table :2 

   Table 2
   +------+------+-------+---------+----------------+------------------+
   | PANI |      | IPsec | Call-ID | Register-Timer | P-Associated-URI |
   +------+ IMSI +-------+---------+----------------+------------------+
   | PANI |      | IPsec | Call-ID | Register-Timer | P-Associated-URI |
   +------+------+-------+---------+----------------+------------------+

   - Additional optional tag with name=dual, need to send during
     REGISTRATION to the Network. This parameter will be send to the IMS
     network along with PANI [RFC7913] header, in the below format

       PANI=.......;dual

    The Optional tag=dual, initiates the PCSCF to store two entries of a
    user's registration data.

   - Upon successful dual registration, in the above scenario after
     second registration via wifi access, re-fresh register request is
     send with change in PANI header value which was sent earlier.

   - Register request sent on RAN access again will have optional
     tag=dual.

   - In case of loss of radio access and non-reachability, a re-register
     request will be sent to network via other access type to update the
     network registration status.

   - For example, dual REGISTERED 5G UE lost connectivity on wifi.
     Whether or not UE's initiated de-register request for Wifi access
     reached IMS network, a re-register request will be sent on RAN
     access with no optional tag=dual on PANI header. This indicated
     loss of wifi access type and P-CSCF will mark will update the user
     registration status stored locally by erasing of wifi access.

sinha                   Expires December 17, 2018              [Page 4]

Internet-Draft      5G Dual Registration Dual Access           June 2018

   - For MT (Mobile terminating) call scenario, terminating S-CSCF will
     route the INVITE request to the terminating P-CSCF. Terminating
     P-CSCF will forward the INVITE request based on current
     registration status of access type. 

   - If UE had IMS registration successful over both access type RAN and
     wifi, dual access, indicating UE is reachable over two access type.
     Terminating P-CSCF forwards INVITE on both access type like a
     parallel forking. SIP response 183 (Session Progress) received
     first from either access type will be processed and received on
     this access type will be discarded. Henceforth, bearer creation
     over access network via diameter AAR/AAA request with PCF function
     will be triggered with accepted response of 183 session-progress
     access-type.

   - If UE had registration successful with only single access-type,
     then terminating P-CSCF forward INVITE on registered access type as
     a normal procedure. 

5. Security Considerations

   Security considerations related to the 5G systems are discussed in
   [NGMN].  Due to the request for intrinsic realization of security
   such aspects have to be considered by design for architecture and
   protocols.

   Especially as a joint usage of resources and network functions by
   different separate logical network slices (e.g. in terms of virtual
   network functions) seems to be inevitable in the framework of 5G the
   need for strong security measures in such an environment is a major
   challenge.

6. IANA Considerations

   This document registers a new option tag based on the IANA
   registration process of RFC 3261.

6.1 IANA Registration of the "dual" Option Tag

   This specification registers an option tag, dual.  The required
   information for this registration, as specified in RFC 3261, is:

    Name       : dual

    Description: This "dual" tag is for informing the SIP Register
                 Server that about UE dual access mode being currently
                 active.
    
    Usage      : "Dual" optional tag to be using with sip header - PANI,
                  abbreviated as P-asserted Network Info.

    Scope      : User side- it is supported at UE device             
                 Network side-it is supported at P-CSCF or SBC of IMS
                 network. 

sinha                   Expires December 17, 2018              [Page 5]

Internet-Draft      5G Dual Registration Dual Access           June 2018


7. Privacy Considerations

   Support of full privacy of the users (customers and tenants / end
   service providers) is a basic feature of the next generation trusted
   and reliable communications offering system.  Such a high degree of
   ensured privacy shall be reflected in the proposed architecture and
   protocol solutions.

   Especially as Identifiers and mapping of locators to them are
   addressed some privacy concerns arise.  Mobility solutions tend to
   expose unique identifiers.  A solution inside the mobile network
   exposes these identifiers to the network operator, which is not a big
   deal since the network operator already has information about the
   device's location.  In contrast, an IP level solution exposes both
   the identifiers and the locations at the IP layer.  That means that
   web sites, for example, can now track the device's successive
   locations by watching the IP address.  Solutions such as transporting
   the identifiers not as part of the IP header should be considered.

8.  Acknowledgements

   This work has been partially performed in the framework of the
   cooperation Config.  Contributions of the project partners are
   gratefully acknowledged.  The project consortium is not liable for
   any use that may be made of any of the information contained therein.

   Comments, constructive criticisms from Karthik Palaniswamy and
   Nagesh V. J.  are respectfully acknowledged.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

    [RFC7913] C. Holmberg., P-Access-Network-Info ABNF Update,
              <https://tools.ietf.org/html/rfc7913>.

9.2.  Informative References

   [TS23.501]
              "3GPP TS23.501, System Architecture for the 5G System
              (Release 15)", March 2018.

   [TS36.300]
              "3GPP TS36.300, Evolved Universal Terrestrial Radio Access
               (E-UTRA) and Evolved Universal Terrestrial Radio Access
               Network (E-UTRAN); Overall description", March 2018.


sinha                   Expires December 17, 2018              [Page 6]

Internet-Draft      5G Dual Registration Dual Access           June 2018



   [TS23.502]
              "3Procedures for the 5G System", March 2018.

   [TS23.228]
              "IP Multimedia Subsystem (IMS)", March 2018.

   [TR38.801]
              "Study on new radio access technology: Radio
               access architecture and interfaces", March 2017.

   [TR23.793]
              "Study on Access Traffic Steering, Switch and Splitting
               support in the 5G system architecture.", April 2018.

   [TR23.793]
              "Study on Access Traffic Steering, Switch and Splitting
               support in the 5G system architecture.", April 2018.

   [ETSI GR NGP 004]
              "Next Generation Protocol (NGP):Evolved Architecture for
               mobility using. Identity Oriented Networks.",January 2018

   [ETSI GR NGP 001]
              "Next Generation Protocol (NGP); Scenario Definitions".
               ,May 2017

   [NGMN]     
              NGMN Alliance, "NGMN White Paper", February 2015.

Authors' Addresses

   Sunil Kumar Sinha
   FF-01, Rainbow Residency,
   Green Glan layout,
   Bellandur, Bangalore
   Karnataka,
   India

   Email: sunilkumarsinha9@gmail.com


   Amardeep Sinha
   C-1003, Yashodeep Heights,
   Sec-29C, Airoli,
   Navi-Mumbai, Maharastra
   India

   Email: sinha.amardeep@gmail.com


sinha                   Expires December 17, 2018              [Page 7]

Internet-Draft      5G Dual Registration Dual Access           June 2018


   Amit Mishra
   Flat No: 208, 16th Block,
   Sun City Apartments,
   Iblur Junction, Sarjapur Signal,
   Bengaluru, India

   Email: amit.j.mishra@gmail.com

   
   Manish Srivastava
   Gr Sagarnivas,
   Central Jail Road,
   Bangalore, Karnataka,
   India

   Email: manishshree92@gmail.com

































sinha                   Expires December 17, 2018              [Page 8]