User Plane Function Distribution and Local Break-Out


  • UPF Distribution/Shunting capability -- distributing User Plane Functions in the appropriate Data Center Facilities with qualified compute hardware for routing the traffic to desired applications and network/processing functions/applications.
  • Local Break-Out (LBO) – Examples: video traffic offload, low latency services, roaming optimization.

The UPF Distribution use case distinguishes between two scenarios:

  • UPF Interconnection. The UPF/SPGW-U is located in the MNO network and needs to be interconnected on the N6/SGi interface to 3PE and/or PCE/PCC.
  • UPF Placement. The MNO wants to instantiate a UPF/SPGW-U in a location that is different from their network (e.g. Customer Premises, 3rd Party Data Center)

UPF Interconnection Scenario

Assumptions:

  • MNO hosts UPF/SPGW-U in their network.
  • MNO provisions all UPF functions.
  • MNO may request UPF Interconnection for Sgi/N6 interface in a required Metro to 3PE/PCE via APIs (on P2)
  • Bare Metal Orchestration Provider and Interconnect Provider expose Data Center Location / Metro to PCEI Enabler via APIs (on P3 and P4)
  • 3PE and PCE providers expose Data Center Location / Metro to PCEI Enabler via APIs (on P5 and P8/P7)
  • PCEI Enabler may request Bare Metal Orchestration for Distributed UPF via APIs (on P3)
  • PCEI Enabler may request Interconnect for MNO UPF (L2/L3) via APIs (on P4)
  • PCEI Enabler may request PCC/PCE and/or 3PE Controller to instantiate workload instances for LBO processing via APIs (on P8/P5)

UPF Interconnection (N6/SGi) Call Flow Sketch

Notes:

  • Does not include interconnect to 3PE/PCE/PCC - to be added
  • Does not include 3PE HW Orchestration - to be added
  • Does not include UPF LBO Orchestration - to be added
  • Does not include 3PE/PCE Workload Orchestration - to be added


UPF Placement Scenario

Assumptions:

  • MNO supports CUPS (5G NSA) and/or UPF (5G SA).
  • MNO may request UPF Placement / Metro, and 3PE/PCE Access / Metro, via APIs (on P2)
  • Bare Metal Orchestration Provider and Interconnect Provider expose Data Center Location / Metro to PCEI Enabler via APIs (on P3 and P4)
  • 3PE and PCE providers expose Data Center Location / Metro to PCEI Enabler via APIs (on P5 and P8/P7)
  • PCEI Enabler may request Bare Metal Orchestration for Distributed UPF via APIs (on P3)
  • PCEI Enabler may request Bare Metal Orchestration for 3PE via APIs (on P3)
  • PCEI Enabler may request Interconnect for Distributed UPF N3/S1 and N6/SGi traffic (L2/L3) via APIs (on P4)
  • PCEI Enabler may expose UPF management access to MNO
  • MNO may provision the Distributed UPF over management access
  • PCEI Enabler may provision UPF connectivity and LBO configuration (based on the UPF provisioning model) over P2’ using appropriate protocols
  • PCEI Enabler may request PCC/PCE and/or 3PE Controller to instantiate workload instances for LBO processing via APIs (on P8/P5)



UPF Placement Call Flow Sketch

Notes:

  • Does not include interconnect to 3PE/PCE/PCC - to be added
  • Does not include 3PE HW Orchestration - to be added
  • Does not include UPF LBO Orchestration - to be added
  • Does not include 3PE/PCE Workload Orchestration - to be added


UPF Placement Options


API Structure

To be added

UPF  Interconnect Options


UPF Hardware Selection / Orchestration

UPF Configuration Orchestration - Local Break-Out Options


3PE/PCE Workload Instance Distribution

To be added

Location Services

  • Location Services -- location of a specific UE, or identification of UEs within a geographical area, facilitation of server-side application workload distribution based on UE and infrastructure resource location.

Assumptions:

  • MNO provides a Location Service (LS) compliant with OMA Zonal Presence API (OMA-TS-REST_NetAPI_ZonalPresence)
  • MNO may expose the Location Service via the Network Exposure Function (NEF)
  • A Public Cloud Edge (PCE) instance is associated with a Zone (collection of Access Points such as small cells) provided by an MNO
  • A 3rd-Party Edge (3PE) instance is associated with a Zone (collection of Access Points such as small cells) provided by an MNO
  • An application/workload in the PCE requires Location Information (e.g. coordinates of the Access Point) for the UE/subscriber
  • An application/workload in the 3PE requires Location Information (e.g. coordinates of the Access Point) for the UE/subscriber
  • PCEI Enabler facilitates Zonal Presence API Request/Response routing between PCE and the MNO LS and between the 3PE and the MNO LS



Azure IoT Edge

Assumptions:

  • MNO hosts UPF/SPGW-U in their network.
  • MNO provisions all UPF functions.
  • MNO may request Deployment of IoT Edge on Bare Metal or NFVi via APIs (on P2)
  • PCEI Enabler IoT Edge Deployer may request HW or Virtual resources (e.g. VM/Container) (on P3)
  • PCEI Enabler IoT Edge Deployer may provision IoT Edge (install runtime, deploy standard modules, register with IoT Hub) via APIs/Deployer Code (on P8/P5)
  • PCEI Enabler may request Interconnect for IoT Edge between MNO and Azure (L2/L3) via APIs (on P4)
  • PCEI Enabler may request UPF LBO for MNO to direct customer traffic to IoT Edge (on P2/P2’)
  • PCEI Enabler may facilitate deployment of custom IoT Edge modules

PCEI Enabler IoT Edge Deployer Functions

  • Deploy a base Ubuntu VM
  • Download and Install Microsoft GPG public key to apt config
  • Install moby engine and cli
  • Install azure iot edge
  • Modify iot edge config file using customer defined parameters (azure hub url, keys, scope id, etc)
  • Deploy iot edge agent
  • Deploy iot edge hub module
  • Install certificates if edge is used as a gateway
  • Restart iot edge


PCEI Enabler IoT Edge Interconnect Functions

  • Request virtual connectivity to MNO
  • Request virtual connectivity to Azure (e.g. ExpressRoute)

PCEI Enabler IoT Edge Software Distribution Functions


PCEI Enabler for Azure IoT Edge Implementation

Architecture and Interfaces


PCEI Enabler Structure



PCEI for Azure IoT Edge Call Flow (High-level)

Openstack HEAT Example

HEAT Template and Environment Files

Template (pcei_base.yaml)

#####

heat_template_version: 2013-05-23

description: Heat template that deploys PCEI IoT Edge VM in Openstack


##############
# #
# PARAMETERS #
# #
##############

parameters:
pcei_image_name:
type: string
label: Image name or ID
description: Image to be used for compute instance
pcei_flavor_name:
type: string
label: Flavor
description: Type of instance (flavor) to be used
os_private_net_id:
type: string
label: os management network name or ID
description: Private network that connects os components and the VNF
os_private_subnet_id:
type: string
label: os management sub-network name or ID
description: Private sub-network that connects os components and the VNF
os_private_net_cidr:
type: string
label: os private network CIDR
description: The CIDR of the protected private network
pcei_private_ip_0:
type: string
label: VNF IP Address
description: IP address that is assigned to the IoT Edge
pcei_name_0:
type: string
label: VNF name
description: Name of the vPacketGenerator
key_name:
type: string
label: Key pair name
description: Public/Private key pair name
pub_key:
type: string
label: Public key
description: Public key to be installed on the compute instance

#############
# #
# RESOURCES #
# #
#############

resources:
random-str:
type: OS::Heat::RandomString
properties:
length: 4

my_keypair:
type: OS::Nova::KeyPair
properties:
name:
str_replace:
template: base_rand
params:
base: { get_param: key_name }
rand: { get_resource: random-str }
public_key: { get_param: pub_key }
save_private_key: false


# Instance behing vRouter
pcei_private_0_port:
type: OS::Neutron::Port
properties:
network: { get_param: os_private_net_id }
fixed_ips: [{"subnet": { get_param: os_private_subnet_id }, "ip_address": { get_param: pcei_private_ip_0 }}]

pcei_0:
type: OS::Nova::Server
properties:
image: { get_param: pcei_image_name }
flavor: { get_param: pcei_flavor_name }
name: { get_param: pcei_name_0 }
key_name: { get_resource: my_keypair }
networks:
# - network: { get_param: os_private_net_id }
- port: { get_resource: pcei_private_0_port }
user_data_format: RAW
user_data: |
#cloud-config
password: pcei
chpasswd: { expire: False }
ssh_pwauth: True
runcmd:
- [ sh, -xc, "sed -i 's,#UseDNS yes,UseDNS no,' /etc/ssh/sshd_config" ]
- systemctl restart sshd.service


Environment (pcei_base.env)

#########

parameters:

pcei_image_name: ubuntu1604

pcei_flavor_name: l3

os_private_net_id: provider

os_private_subnet_id: provider

os_private_net_cidr: 10.121.11.0/24

pcei_private_ip_0: 10.121.11.91

pcei_name_0: PCEI-IOT-EDGE

key_name: maskey1

pub_key: ssh-rsa AAAAB3NzaC1y


Openstack HEAT Command

openstack stack create -t pcei_base.yaml -e pcei_base.env


  • No labels

1 Comment

  1. Oleg Berzin

    • UPF Distribution/Shunting capability -- distributing User Plane Functions in appropriate Data Center Facilities on qualified compute hardware for routing the traffic to desired applications and network/processing functions/applications.

    [su] P2

                OB:// P2 for MNO to PCEI for placement, interconnection and hardware orchestration request. The MNO request over P2 will be decomposed by PCEI Enabler into: P3 to interact with BM Orchestrator to orchestrate hardware for UPF (note – this may also include loading the OS and virtualization); P4 to orchestrate L2/L3 interconnect to PCE/PCC/3PE. After the P3 and P4 tasks are complete – the PCEI Enabler will return results to MNO over P2. MNO will proceed with UPF provisioning over P2/P2’ or directly via management interface.

    •             Local Break-Out (LBO) – Examples: video traffic offload, low latency services, roaming optimization.

    [su] P2’，the LBO solution may vary for different scenarios, can we unify the process to request it? Not sure...

    OB:// Agree with P2’. Specifically for 5G there may be a uniform way to model LBO provisioning using Uplink Classifiers? We need to discuss further. Alternatively the LBO-specific provisioning may be done by the MNO directly via the UPF management access.

    • Location Services -- location of a specific UE, or identification of UEs within a geographical area, facilitation of server-side application workload distribution based on UE and infrastructure resource location.

    [su] P2’, the ability only open to integration partners.

    OB:// Agree with P2’ but also can be done over P2 (using Centralized MNO orchestration or for example Network Resource Function?)

    • QoS acceleration/extension – provide low latency, high throughput for Edge applications. Example: provide continuity for QoS provisioned for subscribers in the MNO domain, across the interconnection/networking domain for end-to-end QoS functionality.

    [su] P2, is there any specific requirements?

    OB:// As in the UPF Distribution case, the request for QoS will be coming from MNO using P2. Then the QoS/performance requirements may be included in P3 (bare metal stack) and/or P4 (interconnect). Specific requirements may be for UPF hardware (CPU, mem, NIC, I/O throughput) and for interconnect/network (bandwidth, resiliency, latency, security).

    • Network Slicing provisioning and  management - providing continuity for network slices instantiated in the MNO domain, across the Public Cloud Core/Edge as well as the 3Rd-Party Edge domains, offering dedicated resources specifically tailored for application and functional needs (e.g. security) needs.

    [su]P2

    OB:// Starts with P2 and then uses P3 and P4 to implement slicing requirements over Sgi/N6 running on the interconnect/network fabric.

    • Mobile Hybrid/Multi-Cloud Access - provide multi-MNO, multi-Cloud, multi-MEC access for mobile devices (including IoT) and Edge services/applications

    [su] P2, is this SDWAN orchestration interfaces?

    OB:// This would be an example of a service/use case that would ride on top of the physical/logical infrastructure orchestrated by the above PCEI Enabler call flows. For example, once the UPF is instantiated/selected and interconnected, one of the slices may carry IoT traffic, while another slice may carry traffic to Edge Compute workloads.

    • Enterprise Wireless WAN access - provide high-speed Fixed Wireless Access to enterprises with ability to interconnect to Public Cloud and 3rd-Party Edge Functions, including the Network Functions such as SD-WAN.

    [su] P2

    OB:// In addition to the above call flows, and assuming that 3PE offers a SD-WAN service, P5 could be used to activate the SD-WAN VNF and connect it to the UPF using P4.

    • Authentication – provided as service enablement (e.g., two-factor authentication) used by most OTT service providers 

    [su] P2’, this one may be similar with location services, only open to partners

    OB:// Any transactions over any of the reference points should involve Authentication.

    • Security – provided as service enablement (e.g., firewall service insertion)

    [su] P2’, not sure about it, it may use 3rd party capability

    OB:// I think Security should be divided between the Control Plane (API) security and the infrastructure security. API security should be part of the PCEI Enabler capabilities and infrastructure security may be implemented/facilitated by PCEI Enaber using APIs exposed by the infrastructure domains (e.g. P4 may be used to implement MACSEC on L2 interconnects between L3 routers connecting UPF and PCE/PCC).