One document matched: draft-reddy-rtcweb-mobile-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-reddy-rtcweb-mobile-00" ipr="trust200902">
<front>
<title abbrev="WebRTC in Mobile Networks">Problems with WebRTC in Mobile
Networks</title>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<author fullname="John Kaippallimalil" initials="J."
surname="Kaippallimalil">
<organization>Huawei</organization>
<address>
<postal>
<street>5340 Legacy Drive, Suite 175</street>
<city>Plano Texas 75024</city>
</postal>
<email>john.kaippallimalil@huawei.com</email>
</address>
</author>
<author fullname="Ram Mohan Ravindranath" initials="Ram Mohan"
surname="Ravindranath">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>rmohanr@cisco.com</email>
</address>
</author>
<date />
<workgroup>RTCWEB</workgroup>
<abstract>
<t>This document describes a set of scenarios in which WebRTC
applications have problems in Mobile Networks.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>The use of cellular broadband for accessing the Internet and other
data services via smartphones, tablets, and notebook/netbook computers
has increased rapidly as a result of high-speed packet data networks
such as HSPA, HSPA+, and now Long-Term Evolution (LTE) being deployed.
Browsers on these devices are becoming close to their desktop
counterparts. So, from that perspective, it is feasible to run WebRTC
applications in them. This draft enumerates problems when WebRTC
application is used on such devices in the above listed networks.</t>
<t>This note focuses on QOS, traffic offload problems and does not
address other mobile network related topics like power consumption,
interface switching and congestion control related issues already being
discussed in <xref target="I-D.isomaki-rtcweb-mobile"></xref>.</t>
</section>
<section anchor="notation" title="Notational Conventions">
<t>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 <xref
target="RFC2119"></xref>.</t>
<t>This note uses terminology defined in .<xref
target="RFC6459"></xref></t>
<t>UE, MS, MN, and Mobile : The terms UE (User Equipment), MS (Mobile
Station), MN (Mobile Node), and mobile refer to the devices that are
hosts with the ability to obtain Internet connectivity via a 3GPP
network.</t>
</section>
<section title="Scope">
<t>This document can be used as a tool to design solution(s) mitigating
the encountered issues. Describing the use case allows to identify what
is common between the use cases and then would help during the solution
design phase. This note aids WebRTC server designers and network
architects to facilitate proper deployment of WebRTC in the mobile
network. WebRTC server could either be deployed in the Mobile Network or
WebRTC server deployed in a 3rd party network trusted by Mobile Network
or Public WebRTC server.</t>
</section>
<section anchor="cell" title="Cellular Networks - QOS">
<t>3GPP has standardized QoS for EPC (Enhanced Packet Core) from Release
8 <xref target="TS23.107"></xref>. 3GPP QoS policy configuration defines
access agnostic QoS parameters that can be used to provide service
differentiation in multi vendor and operator deployments. The concept of
a bearer is used as the basic construct for which QoS treatment is
applied for uplink and downlink packet flows between the MN and gateway
<xref target="TS23.401"></xref>. A bearer may have more than one packet
filter associated and this is called a Traffic Flow Template (TFT). The
IP five tuple (IP source address, source port, IP destination,
destination port, protocol) identifies a packet filter. TFT has other
attributes like Type of Service (TOS)/DSCP. Each MN can have one or
multiple bearers associated with its registration, each supporting
different QoS characteristics. An UpLink Traffic Flow Template (UL TFT)
is the set of uplink packet filters in a TFT. A DownLink Traffic Flow
Template (DL TFT) is the set of downlink packet filters in a TFT.</t>
<t>The access agnostic QoS parameters associated with each bearer are
QCI (QoS Class Identifier), ARP (Allocation and Retention Priority), MBR
(Maximum Bit Rate) and optionally GBR (Guaranteed Bit Rate). QCI is a
scalar that defines packet forwarding criteria in the network. Mapping
of QCI values to DSCP is well understood and GSMA has defined standard
means of mapping between these scalars <xref target="GSMA-IR34"></xref>.
Primarily LTE offers two types of bearer: Guaranteed Bit rate bearer for
real time communication, e.g., Voice calls etc. and Non-Guaranteed bit
rate, e.g., best effort traffic for web access etc. Packets mapped to
the same EPS bearer receive the same bearer level packet forwarding
treatment.</t>
<t>The Web Real-Time communication (WebRTC) <xref
target="I-D.ietf-rtcweb-overview"> </xref> framework provides the
protocol building blocks to support direct, interactive, real-time
communication using audio, video, collaboration, games, etc., between
two peers' web-browsers. WebRTC application would use Interactive
Connectivity Establishment (ICE) protocol <xref target="RFC5245"></xref>
for gathering candidates, prioritizing them, choosing default ones,
exchanging them with the remote party, pairing them and ordering them
into check lists. Once all of the above have been completed then the
participating ICE agents can begin a phase of connectivity checks and
eventually select the pair of candidates that will be used for real-time
communication.</t>
<t>Problems with WebRTC application in 3GPP Network are that</t>
<section title="RTP Session Multiplexing">
<t><list style="symbols">
<t><xref target="I-D.ietf-rtcweb-rtp-usage"></xref> in section 4.4
suggests to put interactive audio, interactive video over the same
5-tuple. This means that QoS cannot be applied to the 5-tuple,
even if it were known. QoS can only be applied by the endpoint by
setting DSCP appropriately on a per-packet basis. This problem can
possibly be solved by the proposal in <xref
target="I-D.ietf-rtcweb-qos"></xref>. But 3GPP networks uses
TFT’s packet filtering information to identify and map
packets to specific bearers. So DSCP value in TFT for the bearer
will not match the DSCP value in the RTP packets sent by the UE
and 3GPP network may not honor the DSCP value in the RTP packets.
In other words both audio/video media streams would be mapped to
the same EPS bearer thus receiving the same bearer level packet
forwarding treatement.</t>
<t><xref target="I-D.ietf-rtcweb-rtp-usage"></xref> in section 4.4
also proposes not to multiplex interactive audio, interactive
video over the same 5-tuple for compatibility with legacy systems.
Mobile Device using WebRTC application in 3GPP network should
prefer this method until a technique to solve the above problem is
identified and deployed in the 3GPP network.</t>
</list></t>
</section>
<section title="Bearer Resource Modification triggered by UE">
<t>If UE is using Public WebRTC server then the UE can request bearer
resource modification procedure for an E-UTRAN as explained in section
5.4.5 of <xref target="TS23.401"></xref>. The procedure allows the UE
to request for a modification of bearer resources (e.g. Allocation or
release of resources) for one traffic flow aggregate with a specific
QoS demand. Alternatively, the procedure allows the UE to request for
the modification of the packet filters used for an active traffic flow
aggregate, without changing QoS. If accepted by the network, the
request invokes either the Dedicated Bearer Activation Procedure or
the Bearer Modification Procedure.</t>
<t>Problems with this approach are :</t>
<t><list style="symbols">
<t>When the UE initiates a call using WebRTC application and
candidate pairs are successfully nominated for each media stream
then WebRTC application should signal the packet filter (5-tuple),
QCI and GBR values for each media stream that would initiate
bearer resource modification or dedicated bearer activation.
WebRTC application need to be aware of the QCI/GBR values required
for the media streams.</t>
<t>This means WebRTC application requires API's to indicate
OS/Modem the packet filters for each media stream to be added,
modified or deleted. WebRTC application would need API's to
indicate OS/Modem the QCI and GBR values for each of the packet
filters. OS/Modem would inturn signal this information to the 3GPP
network that would result in either bearer resource modification
or creation of Dedicated Bearer Activation Procedure.</t>
<t>WebRTC application may also need API's to trigger the
modification of the GBR value for existing packet filters.</t>
</list></t>
</section>
<section title="WebRTC server deployed in 3GPP Network">
<t>Currently 3GPP networks prioritize flows by examining the SDP in
SIP signaling. As WEBRTC also uses SIP and SDP like signaling, similar
mechanisms can be used to deploy WebRTC server in 3GPP network. <list
style="symbols">
<t>3GPP network cannot prioritize all a=candidate lines described
in <xref target="RFC5245"></xref> until WebRTC server receives an
indication of the active media path from the controlling ICE
agent. WebRTC server is aware of the active media path only after
the controlling ICE endpoint follows the procedures in Section
11.1 of <xref target="RFC5245"></xref>, specifically to send
updated offer if the candidates in the m and c lines for the media
stream (called the DEFAULT CANDIDATES) do not match ICE's SELECTED
CANDIDATES (also see Appendix B.9 of <xref
target="RFC5245"></xref>).</t>
<t>WebRTC server deployed in 3GPP network would need "Rx”
like interface to the Policy and Charging Rules Function (PCRF).
The PCRF is the policy server in the EPC. WebRTC server would act
as "Application Function". Dynamic PCC (policy and charging
control) rules are derived within the PCRF from information
supplied by the AF (such as requested bandwidth for the 5-tuple,
Application Identity etc). PCRF forwards PCC rules for the media
stream to the Policy Charging and enforcement function (PCEF) for
Packet scheduling, data packet (Diffserv) marking etc to allow QOS
to be provisioned in the EPC. Bearers would have be
modified/created for media streams, assigned and installed on the
UE.</t>
</list></t>
</section>
<section title="Deep Packet Inspection">
<t>3GPP has a current work item on "Service Awareness and Privacy
Policies" that is chartered to add DPI-related extensions to the PCC
architecture <xref target="TS23.203"></xref>. The (optional) DPI
entity in the EPC is called "Traffic Detection Function" (TDF), and it
performs application detection and reporting of detected application
and its service data flow description to the Policy Control and
Charging Rules Function (PCRF) for performing functions such as
traffic blocking, redirection, policing for selected flows.</t>
<t>If UE is using Public WebRTC server then<list style="symbols">
<t>The session signaling between the WebRTC application running in
the browser and the web server could be using TLS. Moreover WebRTC
does not enforce a particular session signaling protocol to be
used, so network gateways in 3GPP network would fail to inspect
the signalling to identify the 5-tuple used for media stream and
thus fail to prioritize media traffic. Hence derived service
identification <xref target="RFC5897"></xref> would not
succeed.</t>
<t>Network Gateways by inspecting L7 traffic can only identify RTP
but fail to distinguish between IPTV vs. Multimedia, Gaming vs.
Voice Chat, Gaming vs. Voice Chat #2 etc as explained in section
3.1 - 3.3 of <xref target="RFC5897"></xref>.</t>
</list></t>
</section>
</section>
<section anchor="Mobility" title="Mobility">
<t>The following section lists the potential problems If UE ues Public
WebRTC server :</t>
<section anchor="sipto" title="3GPP SIPTO ">
<t>Given the exponential growth in the mobile data traffic, Mobile
Operators are looking for ways to offload some of the IP traffic flows
at the nearest access edge that has an Internet peering point. This
approach results in efficient usage of the mobile packet core and
helps lower the transport cost. Since Release 10, 3GPP starts
supporting of Selected IP Traffic Offload (SIPTO) function defined in
<xref target="TS23.060"></xref><xref target="TS23.401">,</xref>. The
SIPTO function allows an operator to offload certain types of traffic
at a network node close to the UE's point of attachment to the access
network. Limited Mobility support available with SIPTO is explained in
section 2.3.3 of <xref
target="I-D.zuniga-dmm-gap-analysis"></xref>.</t>
<t>If SIPTO is carried out in a Traffic offload Function (TOF) entity
located at the interface of the Radio Access Network i.e. In the path
between the Radio stations and the Mobile Gateway (MGW). The TOF
decides which traffic to offload and enforces NAT for that traffic.
The deployment of a TOF is totally transparent for the UE and hence
does not know which traffic is subject to TOF (NATed at the TOF) and
which traffic is processed by the MGW.</t>
<t>The problem with WebRTC application in such network is that</t>
<t><list style="symbols">
<t>TOF is not aware of the 5-tuple that will used for media and
data channels. ICE agent would gather server reflexive candidates
using STUN and relayed candidates are obtained through TURN. If
STUN messages are offloaded at TOF then UE would learn the
External IP Address/Port provided by the NAT at TOF. Similarly ICE
connectivity checks could also be offloaded at TOF. If UE roams,
though host candidate addresses may not change but NAT will change
resulting in failure to reach the remote peer for the existing
media and data channels. If the media and data channels are
offloaded at the TOF then UE Mobility would result in disruption
of media and data channel traffic.</t>
<t>If UE is using local relayed candidate to reach the remote peer
and roams out of the coverage of RNC/HNB GW then NAT between UE
and TURN server changes, so UE cannot use the previous TURN
allocations and fail to reach the remote peer using local relayed
candidate.</t>
</list></t>
<t><xref target="I-D.wing-mmusic-ice-mobility"></xref> can be used in
such scenarios to provide media stream mobility.</t>
</section>
<section title="IPv4 traffic offload for Proxy Mobile IPv6">
<t>Proxy Mobile IPv6 (or PMIPv6, or PMIP) is a network-based mobility
management protocol specified in <xref target="RFC5213"></xref>.
Network-based mobility management enables the same functionality as
Mobile IP, without any modifications to the host's Protocol stack.
With PMIP the host can change its point-of-attachment to the Internet
without changing its IP address.<xref
target="I-D.ietf-netext-pmipv6-sipto-option"></xref> defines a way to
signal the Traffic Offload capability of a Mobile Access Gateway (MAG)
to the Local Mobility Anchor (LMA) in Proxy Mobile IP Networks. Mobile
access gateway has the ability to offload some of the IPv4 traffic
flows based on the traffic selectors it receives from the local
mobility anchor. Using IP Traffic Offload Selector option <xref
target="I-D.ietf-netext-pmipv6-sipto-option"></xref> mobile access
gateway will negotiate IP Flows that can be offloaded to the local
access network.</t>
<t>The problem with WebRTC application in such network is that</t>
<t><list style="symbols">
<t>MAG and LMA are not aware of the 5-tuple that will used for
media and data channels. If STUN messages are offloaded at local
access network then UE would learn the External IP Address/Port
provided by the NAT at local access network. Similarly ICE
connectivity checks could also be offloaded at local access
network. If UE roams out of the coverage of Local Access Network
though host candidate addresses may not change but NAT will change
resulting in failure to reach the remote peer for the existing
media and data channels. If the media and data channels are
offloaded at the local access network then UE Mobility will result
in disruption of media and data channel traffic.</t>
<t>If UE is using local relayed candidate to reach the remote peer
and roams out of the coverage of Local Access Network then NAT
between UE and TURN server changes, so UE cannot use the previous
TURN allocations and fail to reach the remote peer using local
relayed candidate.</t>
</list></t>
<t><xref target="I-D.wing-mmusic-ice-mobility"></xref> can be used in
such scenarios to provide media stream mobility.</t>
</section>
<section anchor="ipv6" title="IPv6 Prefix with Mobility">
<t><xref target="I-D.korhonen-dmm-prefix-properties"></xref> proposes
extensions to Prefix Information Option <xref target="RFC4861"></xref>
with a mobility flag bit. This would allow for network based mobility
solutions, such as Proxy Mobile IPv6 <xref target="RFC5213"></xref> or
GTP <xref target="TS.29274"></xref> to explicitly indicate that their
prefixes have mobility and therefore, the UE IP stack can make an
educated selection between prefixes that have mobility and those that
do not. WebRTC application for media streams must pick souce addresses
generated from prefixes with 'M' Flag set to 1 in Prefix Information
Option.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>This document does not define an architecture nor a protocol; as such
it does not raise any security concern.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section>
<section title="Acknowledgments">
<t>Authors would like to thank Dan Wing, Basavraj Patil, Magnus
Westerlund and Markus Isomaki for valuable inputs to the document.</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include='reference.RFC.5245'?>
<?rfc include='reference.I-D.ietf-rtcweb-overview'?>
<?rfc include='reference.I-D.ietf-rtcweb-rtp-usage'?>
<?rfc include='reference.RFC.5213'?>
<?rfc include='reference.I-D.ietf-netext-pmipv6-sipto-option'?>
<?rfc include='reference.RFC.5897'?>
<?rfc include='reference.RFC.6459'?>
<?rfc include='reference.RFC.5389'
?>
<?rfc include='reference.RFC.4861'?>
<?rfc include='reference.RFC.2119'
?>
<?rfc include="reference.I-D.ietf-rtcweb-qos"?>
<?rfc include='reference.I-D.zuniga-dmm-gap-analysis'?>
<?rfc include='reference.I-D.korhonen-dmm-prefix-properties'?>
<?rfc include='reference.I-D.wing-mmusic-ice-mobility'
?>
<?rfc include='reference.I-D.isomaki-rtcweb-mobile'?>
<reference anchor="TS23.107" target="">
<front>
<title>End-to-End Quality of Service (QoS) Concept and Architecture,
Release 10, 3GPP TS 23.207, V10.0.0 (2011- 03)</title>
<author fullname="3GPP" surname="3GPP">
<organization></organization>
</author>
<date day="0" month="September" year="2012" />
</front>
</reference>
<reference anchor="TS23.060" target="">
<front>
<title>"General Packet Radio Service (GPRS); Service description;
Stage 2", June 2012.</title>
<author fullname="3GPP" surname="3GPP">
<organization></organization>
</author>
<date day="0" month="September" year="2012" />
</front>
</reference>
<reference anchor="TS23.401" target="">
<front>
<title>General Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E- UTRAN) access
(Release 11), 3GPP TS 23.401, V11.2.0 (2012- 06).</title>
<author fullname="3GPP" surname="3GPP">
<organization></organization>
</author>
<date day="0" month="September" year="2012" />
</front>
</reference>
<reference anchor="TS.29274" target="">
<front>
<title>3GPP, "3GPP Evolved Packet System (EPS); Evolved General
Packet Radio Service (GPRS) Tunnelling Protocol for Control plane
(GTPv2-C)", 3GPP TS 29.060 8.11.0, December 2010.</title>
<author fullname="3GPP" surname="3GPP">
<organization></organization>
</author>
<date day="0" month="September" year="2012" />
</front>
</reference>
<reference anchor="TS23.203" target="">
<front>
<title>3GPP, "Policy and charging control architecture", 3GPP TS
23.203 10.5.0, December 2011.</title>
<author fullname="3GPP" surname="3GPP">
<organization></organization>
</author>
<date day="0" month="September" year="2012" />
</front>
</reference>
<reference anchor="GSMA-IR34" target="">
<front>
<title>Inter-Service Provider Backbone Guidelines 5.0, 22 December
2010</title>
<author fullname="" surname="">
<organization></organization>
</author>
<date day="0" month="September" year="2012" />
</front>
</reference>
</references>
<section title="OS Support">
<t>Moreover WebRTC application cannot mark DSCP values on Operating
Systems like Windows :<list style="symbols">
<t>In Windows setsockopt is completely disabled. See Knowledge Base
Article http://support.microsoft.com/kb/248611.</t>
<t>DSCP is supported and user settable on Symbian S60, Linux, MacOS
X.</t>
</list></t>
<figure>
<artwork><![CDATA[The below program is to set DSCP value of 0x2E was tested on Linux successfully
(Linux k2-server-lnx1 2.6.38-8-generic #42-Ubuntu)
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>
#define MSG "Hello, World!"
int
main(void) {
int sock = -1;
struct sockaddr *local_addr = NULL;
struct sockaddr_in sockin, host;
int tos = 46 << 2; /* Expedited forwarding (0x2e) */
socklen_t socksiz = 0;
char *buffer = NULL;
sock = socket(AF_INET, SOCK_DGRAM, 0);
if (sock < 0) {
fprintf(stderr,"Error: %s\n", strerror(errno));
exit(-1);
}
memset(&sockin, 0, sizeof(sockin));
sockin.sin_family = PF_INET;
sockin.sin_addr.s_addr = inet_addr("10.104.52.145");
socksiz = sizeof(sockin);
local_addr = (struct sockaddr *) &sockin;
/* Set ToS/DSCP */
if (setsockopt(sock, IPPROTO_IP, IP_TOS, &tos,
sizeof(tos)) != 0) {
printf("Error setting TOS: %s\n", strerror(errno));
}
/* Bind to a specific local address */
if (bind(sock, local_addr, socksiz) != 0) {
printf("Error binding to socket: %s\n", strerror(errno));
close(sock); sock=-1;
exit(-1);
}
buffer = (char *) malloc(strlen(MSG) + 1);
if ( buffer == NULL ) {
printf("Error allocating memory: %s\n", strerror(errno));
close( sock ); sock=-1;
exit(-1);
}
strncpy(buffer, MSG, strlen(MSG) + 1);
memset(&host, 0, sizeof(host));
host.sin_family = PF_INET;
host.sin_addr.s_addr = inet_addr("10.106.3.95");
host.sin_port = htons(12345);
if (sendto(sock, buffer, strlen(buffer), 0,
(struct sockaddr *) &host, sizeof(host)) < 0) {
printf("Error sending message: %s\n", strerror(errno));
close(sock); sock=-1;
free(buffer); buffer=NULL;
exit(-1);
}
free(buffer); buffer=NULL;
close(sock); sock=-1;
return 0;
}]]></artwork>
</figure>
</section>
<!--
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:54:26 |