Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | Korea Communication Market Data | List of Contributors | Become a Contributor |    
 
 
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung   Korean Vendors
 
Real World Private 5G Cases   4 Deployment Models On-Premise Cases 5G Core Control Plane Sharing Cases

5G Core Sharing Cases

   
 
Private 5G Deployment   • Private 5G Frequency Allocation Status in Korea  South Korean government's regulations on private 5G and KT's strategy for entering the market
Cases in Korea   Private 5G Operators |   SK Networks Service (SI) Sejong Telecom (Wire-line Carrier) KT MOS (Affiliate of KT) • Newgens (SI) • NAVER Cloud more >>  
    Enterprise DIY |   Korea Hydro & Nuclear Power (Power Plant) Korea Electric Power Corporation (Energy) • Republic of Korea Navy more >>
 
CHANNELS     HFR Private 5G Solution (my5G)       my5G Solution Components       my5G Key Features        my5G Resources        my5G News          
 
banner
banner
LTE QoS (Part 3) - P2P Traffic BW Control using the LTE QoS
October 25, 2013 | By Dr. Michelle M. Do (tech@netmanias.com)
Online viewer:
Comments (4)
16

In the last two posts (Part 1,  Part 2), we learned about LTE QoS. Now, we will show you an example of controlling P2P traffic using the LTE QoS in the LTE network.

 

Let's say there is a network operator named "NMC Telecom", and it offers a service plan with the following features:

  • No bandwidth limitation for Internet usage
  • Data rate limitation (512 Kbps for download, and 128 Kbps for upload) for P2P traffic such as BitTorrent

To provide such features, NMC Telecom has an LTE QoS architecture built as follows. Below, you can see a UE, an eNB, and an SAE-GW, a combination of S-GW and P-GW.

 

 

 

Before we begin...

 

Deep Packet Inspection (DPI) function is required in order to detect P2P traffic from an LTE system (SAE-GW). This DPI function allows the SAE-GW to look down as deep as the payload (L7), where applications (e.g. web, voice, video, P2P, etc.) are located, in a packet. Just so you know, standalone equipment featuring only the DPI function is already available in the market from Cisco SCE, Sandvine PTS, etc. 


Downlink (DL) Traffic

  1. When traffic from the Internet (PDN) arrives at an SAE-GW, DPI in the SAE-GW checks whether the traffic is P2P traffic or not.
  2. P2P traffic is mapped to Service Data Flow (SDF) = 1 and EPS Bearer ID = 5 (The SAE-GW receives information about where (to which SDF and EPS bearer) to map the P2P traffic from PCRF when a user attaches to the LTE network). 
  3. Since MBR (Maximum Bit Rate) for SDF = 1 is defined as 512 Kbps, the SAE-GW performs rate policing for all the P2P traffic by applying MBR of 512 Kbps (any P2P traffic exceeding 512 Kbps is discarded).
  4. Traffic found by the DPI to be not P2P is classified by a SDF filter (5-tuple based packet classifier). Here, the filter is set as (Source IP, Destination IP, Protocol ID, Source Port, Destination Port) = (*, UE IP, *, *, *), where * means any value (i.e. wildcard). So, all the traffic heading to its own destination, a particular IP address of the UE, is matched by this rule, consequently mapping all the non-P2P traffic to SDF = 2, EPS Bearer ID = 5 (The SAE-GW also receives information about this SDF filter from the PCRF when a user attaches to the LTE network.).
  5. Since MBR (Maximum Bit Rate) for SDF = 2 is defined as "Unlimited", no bandwidth control limitation is applied to all the non-P2P Internet traffic.
  6. Because of "APN-AMBR = Unlimited" (APN-AMBR: a QoS parameter that controls the bandwidth of the traffic sent from the same APN (i.e. Internet in this example) and received at non-GBR EPS bearers), there is no bandwidth limitation for SDF = 1 and SDF = 2. These SDFs are mapped to EPS Bearer ID = 5, and delivered to the eNB through the GTP tunnels. Through the steps 1 to 6 explained so far, the bandwidth for P2P traffic is limited to 512 Kbps, whereas the bandwidth of other Internet traffic is not limited before the traffic was delivered to the eNB. 
  7. For the traffic delivered through EPS Bearer ID = 5 to the eNB, based on the eNB's parameter set as "UE-AMBR = Unlimited" (UE-AMBR: a QoS parameter that controls the bandwidth of all the traffic heading to the UE and received at non-GBR EPS bearers), the bandwidth of the traffic is not limited. The eNB tries to deliver the traffic to the UE to the fullest extent allowed by the available resources over the radio link. 


Uplink (UL) Traffic

  1. When there is traffic from an application in a UE, the UE maps the traffic to EPS Bearer ID = 5 using a TFT filter (The UE cannot distinguish SDFs and only knows to which EPS bearer to send which application. SDFs can be distinguished by SAE-GW (P-GW) only). The UE receives information about the TFT filter from the LTE network when it attaches to the network.
  2. For all the traffic heading to an APN (Internet) in all non-GBR EPS bearers (i.e. the one default non-GBR EPS bearer herein), the bandwidth is controlled by APN-AMBR in the UE. However, since the parameter is set as "APN-AMBR = Unlimited", the UE sends all the traffic, P2P or not, using the maximum available bandwidth.
  3. The UE traffic is delivered to the eNB, which control the uplink bandwidth of the traffic in all the non-GBR EPS bearers sent by the UE based on UE-AMBR. To be accurate, it is wrong to say the UE sends the traffic using the maximum bandwidth and the eNB controls UE-AMBR. Since the eNB gives the UE transmission opportunities based on UE-AMBR (by allocating Resource Block (RB) over the radio link), you should say "The bandwidth of the traffic to be sent over the radio link by the UE is controlled based on UE-AMBR by the eNB". Since the parameter is set as "UE-AMBR = Unlimited", the UE will try to deliver the traffic to the eNB to the fullest extent allowed without any bandwidth limitation.
  4. When the SAE-GW receives traffic from the eNB through EPS Bearer ID = 5, it controls the bandwidth of all the traffic in non-GBR EPS bearers that is heading to the same APN (Internet in this example) by using APN-AMBR. Since the parameter is set as "APN-AMBR = Unlimited", there is no limitation on bandwidth here.
  5. Then, the DPI in the SAE-GW distinguishes P2P traffic and non-P2P traffic (So, it's always the SAE-GW that distinguishes P2P traffic, whether in uplink or downlink.). 
  6. P2P traffic is defined as SDF = 1, and thus its bandwidth is limited to 128 Kbps as set by MBR = 128 Kbps. 
  7. All other Internet traffic are defined as SDF = 2, and they are delivered to the Internet without bandwidth limitation as set by "MBR = Unlimited".

 

This way, we can divide the traffic that travels through one EPS bearer into P2P and other Internet traffic, and then control the uplink/downlink bandwidth of P2P traffic only. 

 

 

Jhon 2014-08-21 16:09:05

Hi netmanias,

 

A PCC rule consists of
- service identifier;
- service data flow filter(s);    

1.so here what is the use of service identifier and service data flow filter ?

2. what is the difference between service identifier and service data flow filter ?

 

Asad 2015-09-07 16:42:39

Service identifier is used to identify a service, a SDF belongs to. SDF/TFT is used to select traffic (filter) based on any criterion to match with a particular service. For example, Service ID for OTT be 1, then we create SDF to select/filter those IP packets which belong to OTT (could be server IP:Port or Protocol etc).

 

Service Identifier is for identification of service while SDF Filter is for selecting the packets based on it.

Tine Shumba` 2019-02-12 18:39:33

Your documents simplified a number of cocepts for me

gur15452 2020-01-01 08:20:32

Nice documentation with Great Diagram

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
Related Contents
08/22/2014
Netmanias Technical Documents
06/11/2014
Netmanias Technical Documents
05/07/2014
Netmanias Technical Documents
04/23/2014
Netmanias Technical Documents
04/08/2014
Netmanias Technical Documents
03/21/2014
Netmanias Technical Documents
02/19/2014
Netmanias Technical Documents
02/09/2014
Netmanias Technical Documents
01/25/2014
Netmanias Technical Documents
 
 
 
 

[HFR Private 5G: my5G]

 

Details >>

 

 

 

     
         
     

 

     
     

Subscribe FREE >>

Currently, 55,000+ subscribed to Netmanias.

  • You can get Netmanias Newsletter

  • You can view all netmanias' contents

  • You can download all netmanias'

    contents in pdf file

     
     

 

     
         
     

 

 

 

View All (858)
4.5G (1) 5G (102) AI (8) AR (1) ARP (3) AT&T (1) Akamai (1) Authentication (5) BSS (1) Big Data (2) Billing (1) Blockchain (3) C-RAN/Fronthaul (18) CDN (4) CPRI (4) Carrier Ethernet (3) Charging (1) China (1) China Mobile (2) Cisco (1) Cloud (5) CoMP (6) Connected Car (4) DHCP (5) EDGE (1) Edge Computing (1) Ericsson (2) FTTH (6) GSLB (1) GiGAtopia (2) Gigabit Internet (19) Google (7) Google Global Cache (3) HLS (5) HSDPA (2) HTTP Adaptive Streaming (5) Handover (1) Huawei (1) IEEE 802.1 (1) IP Routing (7) IPTV (21) IoST (3) IoT (56) KT (43) Korea (20) Korea ICT Market (1) Korea ICT Service (13) Korea ICT Vendor (1) LG U+ (18) LSC (1) LTE (78) LTE-A (16) LTE-B (1) LTE-H (2) LTE-M (3) LTE-U (4) LoRa (7) MEC (4) MPLS (2) MPTCP (3) MWC 2015 (8) NB-IoT (6) Netflix (2) Network Protocol (21) Network Slice (1) Network Slicing (4) New Radio (9) Nokia (1) OSPF (2) OTT (3) PCRF (1) Platform (2) Private 5G (11) QoS (3) RCS (4) Railway (1) Roaming (1) SD-WAN (17) SDN/NFV (71) SIM (1) SK Broadband (2) SK Telecom (35) Samsung (5) Security (16) Self-Driving (1) Small Cell (2) Spectrum Sharing (2) Switching (6) TAU (2) UHD (5) VR (2) Video Streaming (12) VoLTE (8) VoWiFi (2) Wi-Fi (31) YouTube (6) blockchain (1) eICIC (1) eMBMS (1) iBeacon (1) security (1) telecoin (1) uCPE (2)
Password confirmation
Please enter your registered comment password.
Password