[5gangip] Problem areas for 5G

[Bill Gage <[e-mail]>]

I just have a couple of comments, marked by [wg>]  ...

Bill Gage 

Huawei Canada Research Centre
Wireless Technology & Research
Ottawa, Canada

mailto: [e-mail]
tz:     Eastern Time, Canada (UTC-05:00 + 01:00 DST)

> -----Original Message-----
> From: Rex Buddenberg [mailto:[e-mail]]
> Sent: Thursday, October 15, 2015 2:53 PM
> 
> Dirk,
> 
> I just read the i-d and found it to be like viewing 4G through a WiFi
> prism.  This gets some points, but it misses a lot.
> 
> Try this (I've no idea how to fit this stuff into the datatracker....;):
> 
> - topology.  WiFi is a LAN technology -- reach from last router to end
> system.  So it's always at the fringe of the internet.  It's not used
> for router-router interconect.
>      But the 4G protocols provide a contention-free MAC that is stable
> under overload (it's also spectrum-efficient and manageable, qualities
> that WiFi signally lacks).  The contention-free MAC makes the protocols
> suitable for extending the internet to _routers_ on mobile platforms
> (e.g. ships, aircraft, ambulances, fire trucks, to state a few rather
> important ones).  This upsets a few norms that we've had in the (mostly
> wired) internet over the past couple decades.
>
[wg>] I think this is a bit of an over-simplification -- there is no contention-based uplink channel (yet) in LTE but there is certainly contention for resources; that's what the scheduler manages. One can avoid all contention in LTE by, for example, assigning a semi-persistent schedule to a UE, but that typically wastes radio resources and/or impacts latency.

As for 5G (and maybe 4.5G), I believe we will see one or more forms of contention-based uplink channels for small packet bursts to overcome the signalling overheads and latencies associated with current LTE procedures.

> 
> - capacity.  The terrestrial internet is composed of mostly fiber optic
> links provisioned in the 10s of G territory. Further we can routinely
> react to congestion by picking up a dark fiber pair and provisioning it.
> We've solved the congestion control in the terrestrial WAN by
> overprovisioning (actually since 1968).
>
[wg>] This is a generalisation that may not be applicable in all deployments. Many operators lease their backhaul/fronthaul facilities with a cost related to (distance*bandwidth)/(max_latency). So for these operators, adding wireline capacity significantly increases their OPEX.

[wg>] In other instances, a base station may not be served by fibre. Ploughing fibre into the ground is expensive and requires, amongst other things, that one obtain a right-of-way from the nearest fibre attachment point to the base station site. This is especially true for many small cell deployments. In many cases, wireless backhaul is the preferred solution ... and you are back to square one -- limited spectrum for backhaul. However, the use of highly directional antennas helps a lot with this.

>      But the radio-WAN is spectrum-limited, not technology limited.
> Most 4G stuff yields 1-2 M of capacity (four orders of magnitude, or
> 10000x, less than the terrestrial-WAN).  And that capacity is shared
> across all the subscriber stations in the segment.  So we do know
> _where_ the congestion will occur -- at the routers bordering the
> radio-WAN.  (Hint: there's a role for diff-serv, imho).
> 
[wg>] What do you mean by "routers bordering the radio-WAN"? Are you talking about (routers associated with) the base stations or do you mean a network node between a base station and a border gateway? Perhaps we should start with a network model ;-)

[wg>] BTW, I don't expect the 4G model to survive into 5G. NGMN (amongst others) have indicated that things like PGW, SGW, PCRF, etc have outlived their usefulness and that a new, leaner network architecture is required.

[wg>] And you are right, we do know where the congestion will occur (Hint: it's always the radio link ;-).

> - shared medium.  The terrestrial WAN is overwhelmingly made up of fiber
> optic cabling.  (So there's no MAC at all in those layer 2 protocols).
> But the radio-WAN is, er, radio.  Shared medium.  This presents a
> requirement and an opportunity:
>   o the requirement is for some means of sharing the medium -- a MAC.
> And you have two choices -- contention and contention-free.  By embrace
> of 4G/5G in the discussion group, you've opted for the latter (only
> correct choice for radio-WAN).
>
[wg>] As I noted above, (current) 4G/LTE only provides a contention-free option. 5G will likely provide both contention-based and contention-free modes of operation, some of which may be back-ported to 4.5G/LTE.

>   o the opportunity is the there is all-sudden an enormous payoff to
> multicast.  Because it provides bandwidth efficiency at exactly the
> place you need it most -- the inelastic capacity radio-WAN.
> 
[wg>] Multicast assumes that multiple devices are simultaneously ready to receive the same content. In an era of on-demand media, this doesn't happen very often so the gains for multicast are almost non-existent. Broadcasting of live events (news, sports) is the only case where this makes sense ... and you don't need the overhead of multicast group management to make this feasible. 
> 
> I'd hope that this discussion would lead to maturing things like
> multicast IP, multicast transport protocols and multicast applications
> that actually use multicast.
>     The corollary is that we need end-to-end (layer 6/7) security in
> these applications, along with management agents.
> 
> I can (vaguely) see a host of problems, looming out there.  A taste:
>   - multicast groups would be highly dynamic.
>   - PKI management for true end-end security is much more involved than
> we've gotten so far.
>   - management (to meet the third principle of high availability
> engineering) has to be much better than it is now (involved discussion
> of what 'better' means herein).
>   - congestion control.  There are beaucoup knobs in the 4G protocols
> but not much idea how to control them or link them to higher layer
> protocols.  For example, what should the linkage between diff-serv and
> tyhe 802.16 MAC be?  And how should an emergency phone call be able to
> differentiate itself fron a non-urgent phone chat?  Set the DSCP?  How
> many apps do that these days?
> 
[wg>] The most significant congestion will occur on the radio link. DiffServ won't help you here. What is required is a transport protocol that is more forgiving than TCP to sudden fluctuations in throughput, error rate, round trip delay, etc and a means to couple conditions at the (radio) link layer to decisions at the transport (and application) layer. In other words, a better end-to-end, cross-layer protocol stack design.

[wg>] As for security, I see the big challenge is in the area of massive deployments of low cost MTC devices. we need authentication and, perhaps, privacy solutions that match the simplicity and cost of MTC devices, the hands-off deployment of those devices, and the sporadic nature of machine-type communications.

[wg>] The current mobility solutions don't work well in a network model of dense small cells where a change in attachment point can occur suddenly due to movement of the device or due to changes in the radio link environment (e.g. interference, shadowing). They also don't work well for devices that sporadically transmit small packet bursts (e.g. background traffic for applications on a smartphone, or most machine-type communications).
> 
> Hoping this starts a productive discussion ....
> 
[wg>] Me too :-)   Cheers ...
> 
> b
> 
> 
> On Thu, 2015-10-15 at 15:44 +0200, [e-mail] wrote:
> > Dear Fuyou, all,
> > Thank you for posting the announcement to the list. I think this draft
> is useful describing some performance issues due to wireless
> characteristics occurring and impacting upcoming systems (e.g. jitter due
> to as well as without congestion) and which have to be mitigated by
> correspondingly improved access and transport control mechanisms in future
> (5G) networks.
> > BTW other aspects which could be discussed here may also be related to
> SFC/SDN/NFV/... issues such as described in draft
> > "Service Function Chaining Dataplane Elements in Mobile Networks"
> http://www.ietf.org/internet-drafts/draft-aranda-sf-dp-mobile-00
> >  ... but also in various others listed rather exhaustively in
> http://tools.ietf.org/googleresults?cx=011177064926444307064%3Arsqif7nmmi0
> &q=5G&cof=FORID%3A9
> > ;-)
> >
> > Thanks for joining the discussion!
> > Best Regards
> > Dirk
> > -----Original Message-----
> > From: 5gangip [mailto:[e-mail]] On Behalf Of Miaofuyou
> (Miao Fuyou)
> > Sent: Donnerstag, 15. Oktober 2015 03:57
> > To: [e-mail]
> > Subject: [5gangip] FW: I-D Action: draft-johansson-cc-for-4g-5g-00.txt
> >
> >
> > > -----Original Message-----
> > > From: I-D-Announce [mailto:[e-mail]] On Behalf Of
> > > [e-mail]
> > > Sent: Thursday, October 15, 2015 2:17 AM
> > > To: [e-mail]
> > > Subject: I-D Action: draft-johansson-cc-for-4g-5g-00.txt
> > >
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > >
> > >
> > >         Title           : Congestion control for 4G and 5G access
> > >         Author          : Ingemar Johansson
> > > 	Filename        : draft-johansson-cc-for-4g-5g-00.txt
> > > 	Pages           : 14
> > > 	Date            : 2015-10-14
> > >
> > > Abstract:
> > >    This memo outlines the challenge that 4G and 5G access brings for
> > >    transport protocol congestion control and also outlines a few
> simple
> > >    examples that can improve transport protocol congestion control
> > >    performance in 4G and 5G access.
> > >
> > >
> > >
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-johansson-cc-for-4g-5g/
> > >
> > > There's also a htmlized version available at:
> > > https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-00
> > >
> > >