One characteristic of some mobile data applications is that they generate small data packets, e.g. IM chatting, heartbeat like operation compared to legacy CS/PS services and HTTP/WAP browsing services. Small data packets are exchanged frequently when mobile data application runs on a UE. The time interval between heartbeat messages is often several seconds for some applications, IM presence status update information may change frequently which is compounded by generating large number of small data packets as an update message is pushed to all friends in the buddy list. When looking at packet traces of major internet POPs [9], [10], [11] and [12], it is clear that roughly 40% of the packets on the Internet today are less than 50 Bytes for IPv4 traffic. Similar observations have been seen in the traffic analysis for wireless access technologies as well [13] and [14]. These are rather large fraction of packets in terms of the total number of packets that flow through the network. These packets could contain a variety of payloads such as TCP ACKs and application related payloads such as VoIP silence suppression and other small payloads. When these small sized IP packets get transmitted over the 3GPP access, a couple of things are expected to change:

1. ROHC, if enabled will further reduce the size of the packet by compressing the IP/UDP/TCP headers in a very effective manner.
2. The 3GPP access will add PDCP, RLC and MAC related overheads which will bump up the size of the packet.

It is however expected that the net effect of 1) and 2) above will be that the packet size effectively could become even smaller especially in scenarios such as VoIP where the ROHC compression can be quite efficient in bringing down the IP/UDP/RTP headers down to a few bytes in size. This trend of small packets is expected to be exacerbated as status messages, location messages, instant messages, keep alives etc as generated by the current generation of mobile data apps grow considerably over time. Hence it is imperative that 3GPP accesses provide enough mechanisms to ensure optimal delivery of such small data packets. It is to be noted that with IPv6, the small data packet problem will remain the same over 3GPP access even though the IPv6 header is much larger. This is due to the application of ROHC over 3GPP access. The frequent exchange of large amount of small data packets may reduce network efficiency and waste network resources, e.g. some IM applications may consume more network resources to transmit same amount of data than HTTP/WAP browsing applications.

Some existing "always on" mobile data applications [5] and [6], such as IM, Social networking apps etc are currently bringing some challenges to operator networks. In general, these mobile data applications involve interactive communications, through operator network, with their application servers in the internet. The server and the application on the UE periodically exchange "heartbeat" messages ( also Known as keep-alives) to keep the application session alive and also to avoid the expiry of NAT mapping which causes IP session disconnection. In addition to periodic keep-alive messages, the applications also generate frequent status update messages to notify the users of status updates relating to the application. Some examples include presence information of buddies in an IM buddy list, update of user location upon user "check in", update of "Facebook likes" to a user's friends, etc.

• Frequency of Keep-alive messages:
  • VoIP apps such as Skype and Fring generate keep-alive messages from once every 30 seconds to every 8 minutes [4] and [7].
• Frequency of Status update messages:
  • Social networking applications such as FindMe generate status update messages upon geographic position changes. The frequency of such messages ranges from sporadic over a day (e.g. changing from home to work to gym then back to home) to periodic up to every 60 seconds [8].
  • Social networking servers push content and presence update messages of the subscriber's friends to the applications on the UE (e.g. Facebook posts the activities when your friend "likes" a particular article or "becomes a fan" of a particular group). The frequency of such content and presence update messages is estimated in the order of every few minutes [see Annex A].

Two more aspects that can aggravate the impacts of status update and keep-alive messages are:

• These messages can be mobile-originated (MO) or mobile-terminated (MT), e.g. periodic FindMe messages can come from change of location of your friends or can come from the updates of your own location.
• It is not uncommon that a UE will install multiple applications, where each application generates these update/keep-alive messages autonomously.

When the transmission of keep alive or status update messages are completed, and upon detection of user inactivity, the UE may be moved to a low power state (e.g. from connected to idle) in order to save the UE battery power. As a result, when the average frequency of status update and/or keep-alive messages is greater than the inactivity timer, the UE will have to cycle among idle, wake up, re-establish the connection, send or receive the update message(s), go back to idle and so on. Figure 2 further illustrates the timing when the UE experiences such frequent idle-active mode transition problem. From the left-most of the Figure, after the phone finishes some data traffic, it stays on active mode for a while and switches to idle state to save power. Soon after the phone enters idle, application #1 generates an update message and the phone wakes up, transmits some signaling messages to establish the connection. We note that, the phone might consume more energy in sending signaling messages than it's in active mode but sending no message. After establishing the connection, it sends the update message and again stays in active state for a while before going to idle state. This cycle repeats as other applications also send/receive update messages (e.g. some MT update messages pushed by the server of app #2 and MO update messages generated by app #3).

We can see that, when the UE constantly flips between active and idle state, there are two problems observed.

• Increased control plane signalling:
  There are excessive signaling overhead (both in RAN and in CN) to just send these occasional, very small update messages. To send just one update message, it may take one round of idle-active transition which may incur significant signaling overhead, including multiple RRC messages in RAN (e.g. Service Request, Radio Bear Establishment/Release, and Paging when message is MT) and EPC signaling messages (e.g. Service Request, Connection Setup/Release).
• Reduced battery life of UE:
  In the worst case scenario, when multiple applications generate update messages soon after the phone enters idle state, the energy consumption of the phone increases due to constantly flipping between active and idle state, it may be higher than if the phone just remained in active mode.

Table 1 summarizes the problem scenarios, the sources of problems, and the affected elements of the frequent idle-active state transition scenarios.

One of the characteristics of Push-to-talk over Cellular (PoC) service is the frequent start of service. Generally, PoC service is intended for business use as PoC calls are mostly "one to many" calls. Each time users start up the application, the UE goes directly from idle to active, and each user takes an independent wireless resource simultaneously. This means that the resource consumption will be large and will produce a large volume of signalling when many users join the call. As the capacity of network is limited, additional signalling produced by users' frequent start of PoC application can lead to shortage of wireless resources and network congestion. In addition, the frequent start of application will reduce battery life of UE.

Internet live content streaming that offers live TV viewing experience and real-time coverage of popular events [15], [16] has become increasingly popular. In the case of breaking news TV coverage or popular sports events, large numbers of interested viewers flock to the content streaming website and are eager to view the same live program. This phenomenon creates a surge in number of streams trying to flow through the network, consequently creating congestion in the network, especially in the air interface as bandwidth is a scarce resource [17]. Unlike on-demand based content streaming, Internet live content streaming poses unique challenges to the network operators' bandwidth management strategy because many live events/TV draw a huge crowd of viewers clogging network bandwidth at the same time. It is worth noting that, even though viewers are all interested in the same program, current Internet live content streams are delivered to wireless subscribers in the form of multiple streams of unicast traffic. Since many live content streaming sources come from the Internet rather than the multicast/broadcast services hosted by the network operator, the broadcasting infrastructure within the operators' network, e.g. MBMS [18], can not be utilized to deal with such situations.

With hundreds of thousands of mobile data applications developed by amateur developers on open platforms such as Android and Apple iOS, the emergence of intentionally or accidentally malicious mobile data applications is becoming increasingly high [19], [20]. So far most of the intentionally malicious programs target the UE, such as stealing users' identity, contacts, or making premium SMS/phone calls without users' knowledge [21]. Accidentally malicious programs could be categorized as those applications that are poorly written in turn leads to sub-optimal behaviour of UEs in the operator's network. Instances of such applications are ever increasing due to a huge base of amateur application developers. Furthermore, the problem could be compounded by the presence of a large number of UEs running one or more accidentally malicious programs. Intentionally malicious or accidentally malicious applications could potentially lead to intentional or accidental Distributed Denial of Service (DDoS) as detailed in this use case. Distributed Denial of Service (DDoS) attacks usually involve one computer instructing multiple (infected) computers to attack multiple networks or hosts, using the infected computers to mount a powerful, coordinated attack [22]. The effects of DDoS attacks are usually in the form of inundating the victim networks/hosts and blocking legitimate visitors. In the context of Mobile Data Application based DDoS attack in wireless broadband networks, the attackers target is to paralyze the wireless networks and take the network and subscribers hostage. The attackers' strategy can be described as follows. The attackers first publishes the malicious programs, often disguised as a legitimate applications, on the open development platform for users to download. The attackers can easily keep track of how many users have downloaded the program, for example by using the download counter provided on the development platforms. When there are enough users that have downloaded and unknowingly infected their devices with the malicious program, the attackers utilizes the back-door left at the malicious program (e.g. Trojan horse) to coordinate simultaneous attack toward the wireless network. Accidental DDoS occurs when a lot of UEs end up downloading one or more accidentally malicious programs - which are poorly written applications and cause sub-optimal UE behaviour in the operator network. The sub-optimal behaviour could be in the form of chatty collaboration between UEs, establishing frequent and large number of connections from the UE etc., often leading to excessive data and signalling usage by the UE. This effect can get compounded with higher number of UEs downloading and executing such accidentally malicious applications as well as with more accidentally malicious applications running per UE. In summary, even though the accidentally malicious application is not intended to attack the network resources, it effectively ends up doing so.

1. Formats and impacts of the attacks: In one form of the attack, the applications can coordinate the infected devices to initiate continuous and possibly synchronized attach requests to overwhelm the network, causing congestion in both radio links and backhaul links. On the other hand, the infected devices can be co-ordinated to initiate useless but bandwidth-demanding traffic, both uplink and downlink, to inundate the network. The impact of such attack is waste of resources in the network and potentially overage of data charges to subscribers.
   In addition, both types of attacks can cause severe damage to the wireless network by blocking legitimate users from using the network and potentially overload and bring down the network making it temporarily out of service.
2. Scale and affected areas of the attacks: the scale and affected areas of the attacks will depend on geographic distribution of infected devices. If large numbers of infected devices in one cell launch attacks at the same time, the radio links become the victim. If the infected device are distributed across an area that is covered by a few cells, the coordinated attack will likely congest the backhaul and elements in access network, e.g. expose processing bottleneck in MME or S-GW, or cause congested links between eNB-MME/S-GW.
   It is worth noting that, with the increasing popularity of devices capable of position techniques, in the event of malicious attacks, the attackers might leverage such capability to initiate geo-targeted attacks that aim to take down strategic areas that are of high importance of operators' deployments.
3. Challenges in attack detection and issues of false alarm: it is hard to detect a mobile application oriented DDoS attack, as they are hard to be distinguished from legitimate access requests/congestions from regular UEs.

Certain push mobile data services do not require real time delivery, e.g. advertisement, service notification, video clips, or some multimedia messaging services. These services may be provided by the network operator, or from third-party providers. Usually these services are distributed to a large number of users in a short period, e.g. news report in rush hours of every morning and every evening. Customers subscribing to these services hope they could receive the content periodically or on time. However the burst of data service will lead to network congestion and impact service experiences. Dense simultaneous push services in a local area may cause the network congestion and service break. As such push services do not have strict real-time requirements, sending them to a large number of devices within a short duration is wasteful and unnecessary, especially when parts of the network are already congested. The delivery of such push services could be delayed until there are sufficient network resources available, which not only optimally utilize network resources, but also guarantee acceptable user experience. In the case where the push services are provided by third-party providers, the lack of knowledge on the current congestion situations of different parts of the network results in the inability of third-party providers to schedule the push services more intelligently. In the case where the push services are provided by the operator, lack of mechanisms and interfaces to schedule the push services (which are not located in the EPC) based on the current network status at the core and access networks also makes it not possible to schedule the push services efficiently.

The background traffic can be large data flow, such as unexpected software version update and large file download. It can also be periodical data transmission, such as regular unwanted collected-data uploading and probing data for connectivity. Unlike on-demand or allowed data traffic, background traffic is usually generated automatically and without users' consent. It causes additional traffic which the user may complain about as they will be charged especially in the case of international roaming.