Your SlideShare is downloading. ×

Machine comms in 3 gpp systems

1,306

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,306
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
79
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. C qM IEEE M ommunications q qM Previous Page | Contents | Zoom in | Zoom out | Front Cover | Search Issue | Next Page MqM q Qmags THE WORLD’S NEWSSTAND® TECHNOLOGY UPDATES ON LTE ADVANCED Machine Type Communications in 3GPP Systems Puneet Jain, Intel Corporation Peter Hedman, Ericsson Haris Zisimopoulos, ZTE ABSTRACT device triggering). SCS can be M2M service provider controlled, that is, deployed outside the 3GPP studies indicate that for mobile net- operator domain (Fig. 1b). In some indirect works to be competitive for mass machine-type deployment models the SCS can be 3GPP opera- applications, it is important to optimize their tor controlled and considered an internal net- support for the expected huge growth of con- work function. In this case, security and privacy nected devices due to uptake of machine-type protection for communication between the 3GPP communications. In this article we briefly network and the SCS is optional. describe the architectural enhancements in In the hybrid model, the AS uses the direct 3GPP systems to better facilitate machine type and indirect models simultaneously in order to communication. We highlight key architectural directly connect to the operator’s network to changes, functionality of new network elements perform direct user plane communications with to support new features such as device trigger- the UE while also using services provided by the ing, packet switched subscriptions including SCS. Similar to the indirect model, for the hybrid short message service via PS domain and SMS in model the SCS can be either M2M service MME. We also describe overload control mech- provider controlled (Fig. 1c) or 3GPP network anisms to prevent overload situations caused by operator controlled. synchronous connection requests from large From the 3GPP network perspective, the numbers of MTC devices to the 3GPP system. direct user plane communication from the AS Finally, we discuss how this work is expected to and any value added control plane related com- evolve in future 3GPP releases. munications from the SCS are independent and have no correlation to each other even though INTRODUCTION they may be servicing the same MTC application hosted by the AS. The end-to-end communications between a machine-type communications (MTC) applica- tion in user equipment (UE) and an MTC appli- 3GPP ARCHITECTURE REFERENCE cation in an external network uses services provided by the Third Generation Partnership MODEL FOR MTC Program (3GPP) system, and optionally services Figure 2 shows the architecture for UE used for provided by a services capability server (SCS). MTC connecting to the 3GPP radio access net- The MTC application in the external network is work (UTRAN, E-UTRAN, GERAN, etc.) via typically hosted by an application server (AS) the Um/Uu/LTE-Uu interface. Blue colored ref- and may make use of an SCS for additional erence points are the new reference points added value added services. The 3GPP system provides to facilitate MTC over 3GPP systems. transport, subscriber management, and other The MTC interworking function (MTC-IWF) communication services, including various archi- is the functional entity that hides the internal tectural enhancements for MTC (e.g., control network topology and relays/translates signaling plane device triggering). protocols used over Tsp to invoke specific func- Different deployment models foreseen for tionality in the public land mobile network MTC between the MTC Application and the (PLMN) (e.g., control plane device triggering). 3GPP network are described below. An MTC-IWF could be a standalone network In the direct model, the MTC application on element or a functional entity of another net- an AS communicates with the UE directly as an work element and always reside in the home over-the-top application on a 3GPP operator’s PLMN (HPLMN). network. This is shown in Fig. 1a. The SCS connects to the 3GPP network via In the indirect model, an AS connects indi- the MTC-IWF in the HPLMN to communicate rectly to the operator network using the services with UE used for MTC. The SCS offers capabili- of an SCS in order to utilize additional value ties for use by one or multiple MTC applica- added services for MTC (e.g., control plane tions. A UE unit can host one or multiple MTC 28 0163-6804/12/$25.00 © 2012 IEEE IEEE Communications Magazine • November 2012C qM IEEE M ommunications q qM Previous Page | Contents | Zoom in | Zoom out | Front Cover | Search Issue | Next Page MqM q Qmags THE WORLD’S NEWSSTAND®
  • 2. C qM IEEE M ommunications q qM Previous Page | Contents | Zoom in | Zoom out | Front Cover | Search Issue | Next Page MqM q Qmags THE WORLD’S NEWSSTAND® applications. The corresponding MTC applica- tions in the external network are hosted on one Control plane or multiple ASs. The SCS provides an applica- User plane tion programming interface (API) to allow dif- M2M service ferent ASs to use the capabilities of the SCS. domain The interface between SCS and AS is not stan- Application Application Application server server server dardized by 3GPP, but other standards develop- ment organizations (SDOs) such as the European Telecommunications Standards Insti- M2M/network tute (ETSI) Technical Committee on Machine- operator domain SCS SCS to-Machine Communications (TC M2M) are expected to standardize APIs. Operator Tsp is a 3GPP standardized interface to facil- boundary itate value-added services motivated by MTC Operator Operator Operator (e.g., control plane device triggering) and pro- network network network vided by an SCS. Tsms is a non-standardized interface that encompasses all the various exist- ing proprietary SMS-SCs to SME interfaces. The M2M device T4 interface is used by the MTC-IWF to route a domain device trigger as an MT-SMS to the SMS-SC in UE UE UE the HPLMN. T5a/b/c interfaces are intended to provide optimized paths for device trigger deliv- ery and possibly other services (e.g., small data A. Direct model B. Indirect model C. Hybrid model service) to the UE. T5a/b/c were not standard- ized in 3GPP Rel-11. The S6m interface is used Figure 1. Deployment scenarios for machine type communications over 3GPP by the MTC-IWF to interrogate the home loca- operator network. tion register (HLR)/home subscriber server (HSS) for mapping an MSISDN or external identifier to the International Mobile Subscriber Identity (IMSI), retrieving serving node informa- the local identifier is used to derive or obtain the tion, and authorizing a device trigger to a partic- IMSI. The combination of the local and domain ular UE. The S6n is an interface between MTC identifiers makes the external identifier globally accounting, authorization, and authentication unique. An external identifier is in the form of a (AAA ) and HSS/HLR to interrogate HLR/HSS URI or NAI (<Local Identifier>@<Domain for mapping IMSI to external identifier(s) and Identifier>) and is mapped to the internal iden- vice versa at the network egress. tifier (i.e., IMSI) by the MTC-IWF. An operator with no shortage of MSISDNs can still use it as an external identifier or construct an NAI using MTC IDENTIFIER an MSISDN as username. The number of devices used for MTC is expect- ed to be several magnitudes higher than the number of devices for human-to-human commu- DEVICE TRIGGERING nication scenarios. Some countries and their One of the key requirements for a 3GPP net- national regulatory authorities have expressed work is to trigger devices from the network to concerns over the numbering requirements (e.g., perform certain application-related tasks. For shortage of E.164 MSISDNs) of new MTC ser- 2/3G devices it is quite common that the devices vices. A large number of MTC services are cur- are not readily attached in the PS domain and rently deployed over circuit-switched GSM do not have IP addresses in order to be reached networks and therefore use E.164 MSISDNs, by the network. Given that the majority of MTC although such services do not require “dialable” applications are data applications, it is important numbers. Therefore, 3GPP architecture has been for the SCS to be able to reach the device in the enhanced to allow delivering communication ser- PS domain; this requires the device to be allo- vices using an alternate identifier, which is called cated an IP address. Device triggering is there- an external identifier. fore relevant for devices that do not always have MTC identifiers can be categorized into: an IP address allocated. For devices that are • Internal identifiers: used within the 3GPP “always on” in the PS domain, the SCS or AS system to identify UE using a subscription can directly communicate with the device in the (or the subscription itself, e.g., when the PS domain (e.g., Long Term Evolution [LTE]- UE is not registered) only devices). • External identifiers: used from outside the To address this requirement, control plane 3GPP system (e.g. at the Tsp interface), to device triggering is defined in 3GPP TS 23.682 refer to UE using a subscription (or the [1] as the mechanism by which an SCS sends subscription itself, e.g., when the UE is not certain information to the device via the 3GPP registered) network to trigger the device to perform applica- The IMSI is used as an internal identifier tion-specific actions that include initiating com- within 3GPP systems. The external identifier is munication with the SCS (for the indirect model) globally unique and has two components: the or an AS in the network (for the hybrid model). domain identifier used to identify where services The Device trigger request message contains provided by the operator network can be information that allows the network to route the accessed (e.g. MTC-IWF provided services); and message to the appropriate device and also IEEE Communications Magazine • November 2012 29C qM IEEE M ommunications q qM Previous Page | Contents | Zoom in | Zoom out | Front Cover | Search Issue | Next Page MqM q Qmags THE WORLD’S NEWSSTAND®
  • 3. C qM IEEE M ommunications q qM Previous Page | Contents | Zoom in | Zoom out | Front Cover | Search Issue | Next Page MqM q Qmags THE WORLD’S NEWSSTAND® Further enhance- IP-SM-GW SMS-SC/ Tsms ments are expected GMSC/ SME IWMSC in future releases to E CDF/ MTC define additional HSS SGd T4 CGF AAA S6n triggering mecha- Gd Rf/Ga S6m nisms such as T5 based triggering, MTC-IWF Tsp Control plane Services Application group based trigger- User plane T5c capability server 1 ing. In addition, fur- server (AS) T5b (SCS) ther enhancements Gi/SGi GGSN/ are expected for P-GW Application T5a server 2 “T4 device trigger- Gi/SGi (AS) ing” to introduce HPLMN overload control and VPLMN priority triggering. MSC Indirect model 1 MME Direct model 2 MTC UE application UE RAN SGSN Hybrid model 1 + 2 S-GW Um/ Uu/ LTE-Uu Figure 2. 3GPP architecture for machine-type communication. allows the device to route the message to the • Transfer of serving SGSN/MME/MSC infor- appropriate application. The information des- mation along with device trigger when tined to the application, along with the informa- addressed by IMSI tion to route it, is referred to as the trigger • Reports to MTC-IWF the success or failure payload. The trigger payload for example upon of delivering a device trigger to device the reception by the device provides information A number of optimizations have been per- to the application that may trigger application formed for device triggering. The most notable related actions. The application in the device as a ones for MTC-IWF are: result may perform indicated actions based on the • It can perform interrogation to obtain serv- information contained in the trigger payload. For ing node information for UE units that do example, it may initiate communication immedi- not have MSISDN. ately or at later point in time with SCS or AS. • It can obtain the serving node information Device triggering is subscription-based. The from HSS and send it to SMSC. This avoids MTC-IWF authorizes device triggering requests the SMSC having to do another query in the based on HSS subscriber data for a specific HSS to obtain serving node information. mobile subscriber and chooses the trigger deliv- • It supports the ability to authorize the SCS ery mechanism that is applicable to the particu- control plane requests. lar type of device. • It selects the most efficient and effective Tsp is a newly defined open interface that device trigger delivery mechanism and allows the MTC-IWF to connect to one or more shields this detail from SCS. SCSs and receive the device trigger request from Further enhancements are expected in future the SCS. Domain selection procedures may be releases to define additional triggering mecha- used in order to select the appropriate MTC- nisms such as T5-based triggering (e.g., using IWF to send the request. generic container over NAS) and group-based Despite the fact that several mechanisms triggering. In addition, further enhancements are have been discussed in 3GPP Rel-11, at the time expected for “T4 device triggering” to introduce of writing the present article the only mechanism overload control and priority triggering. defined is “T4 device triggering,” which uses SMS format in order to send the trigger to the device. SMS IN THE PS DOMAIN The newly added T4 interface based on Since SMS is expected to be used for triggering Diameter includes the following functions: MTC devices en masse, one of the requirements • Connects the MTC-IWF, taking the role of was to control the load these devices cause in the SME, to SMS-SC inside the HPLMN network elements that are also used for human- • Transfer of device trigger, addressed by to-human communication such as a mobile either an MSISDN or an IMSI, from MTC- switching center (MSC)/visited location regis- IWF toward SMS-SC inside the HPLMN terVLR. SMS using PS domain Non-Access 30 IEEE Communications Magazine • November 2012C qM IEEE M ommunications q qM Previous Page | Contents | Zoom in | Zoom out | Front Cover | Search Issue | Next Page MqM q Qmags THE WORLD’S NEWSSTAND®
  • 4. C qM IEEE M ommunications q qM Previous Page | Contents | Zoom in | Zoom out | Front Cover | Search Issue | Next Page MqM q Qmags THE WORLD’S NEWSSTAND® UE MTC 0. Registration application 1 (AppID etc...) MTC Dispatch 2. Device trigger MTC-IWF 1. Device trigger application 2 function (trigger payload) / NW entities (trigger payload) MTC 3. Dispatch DT SCS application 3 (trigger payload) 4. Setup communication Figure 3. High-level device triggering model. Stratum (NAS) procedures has been specified •During the attach and mobility management since Rel-7 but it has been rarely used on the procedures the network provides an indication field primarily because the devices were not to the device when the subscription allows for aware of the network capabilities but also SMS services, subscription data indicate “SMS- because the majority of devices (traditional supported,” and the SGSN supports SMS ser- mobiles) have the need to utilize services from vices via PS domain NAS. the CS domain. •If the device does not need the CS domain Especially for MTC devices, some mobile for services other than SMS, it avoids registra- operators would like to “offload” these devices tion in the CS domain if it receives indication from the CS domain and do not want them to that it can obtain SMS from the PS domain. perform signaling with the MSC. Operators without legacy 3GPP MSC would also like to ENHANCED SUPPORT FOR SMS IN EPC/MME avoid MAP (which uses Signaling System #7) Before the introduction of the SMS in MME based interfaces in their Evolved Packet Core feature, SMS in EPS was supported by connect- network and avoid provisioning 3GPP CS sub- ing an MSC to an MME via an SGs reference scriber data. Therefore an option to deploy SMS point (SMS over SGs), and the MME simply for- in the Evolved Packet System (EPS) was devel- warded SMS messages from and to the device oped and is commonly referred to as “SMS in over SGs. The SMS in MME feature is more MME.” like how SMS works for an SGSN in GPRS, and it reuses the NAS protocol developed for SMS PS-ONLY SMS OVER 2/3G over SGs, which requires the device to perform a In a 2G/3G system, the SGSN can provide the combined EPS and IMSI attach (i.e., in principle function of sending/receiving SMS (i.e., SMS to the device is attaching to both PS and CS be provided via PS domain NAS), and this way domains). By reusing the same NAS protocol as the device does not need to have CS subscrip- for SMS over SGs, the network can keep trans- tion and/or in some cases have CS capability parent to the device whether the network decides altogether. to make use of the SMS in MME or SMS over In the “real world” there is a mix of new and SGs. legacy devices, as well as networks that provide The two subscription profiles described above different capabilities taking roaming into consid- can also be used for SMS in EPC/MME. eration. The new procedures introduce mecha- Figure 5 shows the architecture for support of nisms where the device and network will be able SMS in MME. Not shown in the figure, when to exchange their capabilities and select a mutu- roaming partners are not supporting Diameter in ally supported mechanism for SMS delivery their SMS infrastructure, additional entities are when the device registers with the network. added toward the SMS-GMSC/IWMSC/SMS The 3GPP defined mechanisms avoid the router for mapping between Diameter and MAP “trial-and-error” procedure where the device protocols. Such protocol mapping functions can only registers in the PS domain, and only when be avoided for SMS traffic inside a network and it needs to send SMS it tries, and if it fails it between operators that deploy the SMS in MME attempts to register to the circuit switched (CS) option. For other interconnect and roaming sce- domain at that point. narios, the network still needs to support the For 2G/3G these limitations were addressed MAP interfaces for SMS. in Rel-11, and the following enhancements were defined and specified in TS 23.060 [2]: •Two subscription profiles were introduced: OVERLOAD CONTROL AND one for cases where the device does not have any access to CS domain services and uses SMS SIGNALING REDUCTION exclusively on the PS domain (as indicated by With the expected increase in number of devices the Network Access Mode), and one in which using cellular access for MTC, for standardiza- the device prefers to use SMS in the PS domain tion organization for the global cellular industry if the network also supports this mode of opera- 3GPP considered overload control and signaling tion (called “SMS in SGSN support”) reduction to be the most important features to IEEE Communications Magazine • November 2012 31C qM IEEE M ommunications q qM Previous Page | Contents | Zoom in | Zoom out | Front Cover | Search Issue | Next Page MqM q Qmags THE WORLD’S NEWSSTAND®
  • 5. C qM IEEE M ommunications q qM Previous Page | Contents | Zoom in | Zoom out | Front Cover | Search Issue | Next Page MqM q Qmags THE WORLD’S NEWSSTAND® SMS procedures up to Rel-11 SMS with new Rel-11 procedures In NMO-I: device performs combined MM procedures. Based on device’s subscription profile and whether “SMS in PS Controlled by Network Mode of Operation. domain” is supported, the SGSN may or may not perform Device registration UEs and/or SGSN normally always attempt reg- registration in CS domain in CS domain istration in CS domain when the device has CS In NMO-II: device performs PS registration before CS. If it subscription receives indication of support for “SMS in the PS domain” from the network, it does not register in CS domain Device transmission/ Device normally always uses CS domain for Device uses PS domain NAS if it has received indication of delivery of SMS sending SMS support from SGSN SGSN forwards SMS from/to device if it sup- SGSN indicates support for SMS to the device and to the HSS SGSN procedures ports SMS procedures during MM procedures HSS sends SMS subscription data for both PS HSS can indicate to the SGSN that it has no CS subscriber HSS/HLR procedures and CS domains with no preference for SMS data, or it can indicate “SMS in SGSN support” in case it and subscription delivery domain prefers not to use CS domain Table 1. Comparison of SMS procedures. ensure that mechanisms are in place to protect midnight). To protect against such scenarios the network from excessive signaling that may 3GPP Rel-10 specified a number of functions for occur from the connectivity patterns of large overload control, and also developed some fea- numbers of devices. Such situations would be an tures and extensions in an attempt to limit the issue, say, when the same application logic run- signaling from the devices. Due to its impor- ning in a large number of devices requests tance and the need to further address additional devices to do something at the same time (syn- requirements, the work on overload control has chronized access), or when failure of a network continued in Rel-11 and will likely continue in serving a large number of devices causes these later releases as well. devices to move onto another network and Developed overload mechanisms described potentially overload the network(s) that have not below though motivated by MTC can also be (yet) encountered overload conditions and have used for other use cases (e.g., smart phones) as not failed. An example of synchronized access is normal signaling from large numbers of devices electricity meters that need to report monthly may cause overload independent of whether the electricity usage at the end of the month (e.g., at device is used for MTC or not. MSC/ PGW/ UE SMS-SC HSS MTC-IWF DNS SCS SGSN/ GGSN MME 1. Query DNS 2. Device trigger request 3. Authorization and load control 4. Subscriber information request 5. Subscriber information response 6. Trigger delivery selection T4 Device trigger delivery procedure 7. Device trigger report 8. Action in response to device trigger Figure 4. Basic device triggering procedure. 32 IEEE Communications Magazine • November 2012C qM IEEE M ommunications q qM Previous Page | Contents | Zoom in | Zoom out | Front Cover | Search Issue | Next Page MqM q Qmags THE WORLD’S NEWSSTAND®
  • 6. C qM IEEE M ommunications q qM Previous Page | Contents | Zoom in | Zoom out | Front Cover | Search Issue | Next Page MqM q Qmags THE WORLD’S NEWSSTAND® OVERLOAD CONTROL For many M2M use cases the application is HSS regarded as delay-tolerant; it is not critical if the communication is delayed for some time. This S6c/C S6a characteristic was considered when introducing a new priority level indication for the control plane signaling in 3GPP: low access priority indication SGd SMS-GMSC/ Uu S1-MME IWMSC/ (LAPI). The equivalent indication (establishment UE E-UTRAN MME SMS router cause) on the radio resource control (RRC) level for UTRA and E-UTRA is called delay-tolerant access (a device indicating LAPI would also use Figure 5. SMS in MME architecture. delay-tolerant access as RRC establishment cause). As a result, a new configuration parame- ter was introduced for such devices. MME/SGSN can request the SGWs to selective- When the network is overloaded for some ly reduce the number of downlink data notifica- reason, the general principle for overload con- tion requests sent for downlink low-priority trol is that the network can start to reject access traffic for devices in idle mode. This reduction is attempts from delay-tolerant devices (i.e., those based on a throttling factor and a throttling indicating LAPI before rejecting or blocking delay. The SGW determines whether a bearer is access attempts from other devices; i.e., not indi- for low-priority traffic or not on the basis of the cating LAPI). bearer’s ARP priority level and operator policy. Generally the whole device is configured for If the MME or SGSN experience excessive low access priority. However, there were some load, it can issue an overload message (2. exceptions defined including emergency access OVERLOAD_START) with a load level indica- attempt and access attempts by priority users. tion towards RAN. The RAN will then start Furthermore, in release 11, overriding capability blocking some of the traffic towards the CN (i.e., override low access priority) was introduced node. The means which the RAN rejects device and this gives the ability for certain applications traffic is implementation specific in the RAN to override low access priority configuration. A though CN is able to indicate whether access device configured for low access priority should attempts from devices configured for low access be able to make Emergency accesses in certain priority are to be rejected. cases and therefore such device will be able to When offloading due to an overloaded CN, override overload measures taken when the the RAN may start to reject RRC access device was using LAPI. This is consistent with attempts from devices (3. RRC reject), and normal cellular system procedures where regula- include an extended wait time to the device. The tory requirements dictate such behavior. device will not access the network until the timer Figure 6 shows some overload protection expires, unless the access attempt is for an emer- mechanisms introduced to protect the network gency or high-priority access request. The RRC (CS domain is not shown in the figure, but the reject messages are not protected, and the device CS domain also includes similar functionality). will continue to run the timer even though the Overload may be detected in many different device moves out of the cell where the device ways as operator deploy sophisticated tools to was rejected. Therefore, the timer value is kept measure the load conditions in the network, and relatively short (up to 30 minutes), although upon such detection or even pre-knowledge of such wait timers are only provided to a device events the operator may insert some (0. Opera- configured for low access priority. tor O&M) commands to let the RAN (eNB, Due to limited radio capabilities in GERAN RNC, BSC) or MME/SGSN/MSC nodes offload to reject a number of devices simultaneously some of the traffic that the devices are generat- making access attempts, a new functionality to ing in the system. The nodes may also detect implicitly reject (4. Implicit Reject) devices was overload themselves by measuring the current developed. The implicit reject function works as load in the node. Upon such detection, for exam- follows: ple, the PDN gateway (GW) may start rejecting 1) Prior to making an initial access attempt a new connections (1a. PGW rejecting PDN con- device configured for low access priority reads a nection requests) and indicate a back-off time common control channel block to determine if for a certain Access Point Name (APN) to the an implicit reject condition is indicated. If an MME/SGSN. The MME/SGSN should then implicit reject condition is detected, the device reject PDN connection requests, for the specific will abort its access attempt and start an implicit APN related to that PDN GW during the “PDN reject timer. GW back-off time.” Upon receiving such rejec- 2) Otherwise, while looking for a response to tion including a back-off time, the device starts a its initial or subsequent access attempt, if a back-off timer and will not try to access that device configured for low access priority detects APN until the back-off timer has expired. an implicit reject condition but does not detect The MME/SGSN may also detect overload an access response within the allowed access and reject NAS requests (1b. NAS reject) and response time window, it will abort its access include back-off time values to offload the CN. attempt and start an implicit reject timer. An MME/SGSN may also reject Downlink Data 3)The implicit reject timer has a value ran- Notification requests (1c. Throttling DL data) domly drawn from a uniform probability distri- for low-priority traffic for devices in idle mode. bution within the set {10.0, 10.1, 10.2, … 200.0} Also, to further offload the MME/SGSN, the seconds (inclusive). IEEE Communications Magazine • November 2012 33C qM IEEE M ommunications q qM Previous Page | Contents | Zoom in | Zoom out | Front Cover | Search Issue | Next Page MqM q Qmags THE WORLD’S NEWSSTAND®
  • 7. C qM IEEE M ommunications q qM Previous Page | Contents | Zoom in | Zoom out | Front Cover | Search Issue | Next Page MqM q Qmags THE WORLD’S NEWSSTAND® as part of manufacturing the device, there are two standardized means: by OMA device man- agement (see TS 24.368 [4]) or by SIM OTA (see TS 31.102 [5]). See TS 23.401 [6] and TS 23.060 [2] for more 0. Operator O&M details on overload and congestion control. UE SIGNALING REDUCTIONS 1b. NAS reject 1a. PGW rejecting PDN MME/ connection requests PGW 3GPP also looked into possible signaling opti- SGSN mizations to reduce the signaling load that is 2. OVERLOAD_START generated during certain procedures and scenar- RAN 1c. Throttling 3. RRC reject DL data ios. As an output of that analysis, it was agreed SGW that a change of device behavior could some- 4. Implicit reject times be beneficial and the ability for the opera- tor to control this change of device behavior was 5. EAB RAN included in the specifications. Some examples are listed below •Long periodic update timers, which delay Figure 6. Overview of overload protection mechanisms in the PS domain. the rate at which the device discovers network failures and it reduces the signaling load, but it could delay mobile terminating communication 4) While an implicit reject timer is running in such as a device that did not receive a mobile a device, it shall consider itself unable to make terminating call (missed paging) as it was out of further system access attempts in the current cell coverage would not be paged again until it per- unless it receives a paging notification. forms a RAU/TAU or LAU. However, long The implicit reject function is only developed periodic RAU/TAU and periodic LAU timers for the GERAN radio access; see 3GPP TS could be useful for devices that do not rely on 44.018 [3] for a detailed description of the getting mobile terminating calls immediately or implicit reject function. in a very efficient timely manner. Rejecting devices consumes radio resources •Network mode of operation I behavior, (e.g., RACH resources); therefore, the ability to which enables the possibility to make some bar low- priority devices from accessing the devices perform combined PS and CS registra- radio resources was introduced with Extended tion toward the PS domain while keeping other Access Barring (EAB). EAB applies to all 3GPP devices performing individual registration to the radio access technologies (RATs). PS and the CS domains. It reduces the signaling The EAB logic is described in Fig. 7. For E- load on the serving network and it enables the UTRAN, the device is made aware of a change possibility to make use of long periodic update in the EAB system information block (a dedicat- timers without the network support for per ed SIB for EAB has been added) by a paging device (extended) periodic location update indication (which the device checks at each pag- timers. ing occasion, and typically a 2.56s paging cycle is The complete list of optimizations is available used), which allows only devices configured for in 3GPP TS 24.368 [4]. EAB to read the EAB SIB. For UTRAN, all devices need to read the management informa- tion block (MIB) when the EAB SIB changes. FUTURE DEVELOPMENTS AND PLANS The EAB algorithm for E-UTRAN and MTC related work is ongoing in 3GPP Rel-12 UTRAN is a simple broadcasted barring bitmap and new enhancements/optimizations are consid- for Access Class 0–9 (i.e., similar to UTRAN ered on following areas: Access Class Barring), which provides 10 percent •Support of transmissions of small amounts granularity for barring. The radio network needs of data with minimal network impact (e.g., sig- to rotate access classes by changing broadcast naling overhead, network resources, delay for information. There is also a possibility to bar reallocation) and systems enhancements to mini- only certain roaming categories; that is, devices mizing overheads and signalling caused by fre- not in their home PLMN and/or devices not in quent transmissions of small amount of data the most preferred PLMN of the country. (e.g.: keep-alive or status-update messages) by To support network sharing, the EAB infor- mobile data application (e.g.: social networking mation is sent per PLMN, and up to six PLMNs applications, VoIP applications etc.). can be supported. •Device triggering enhancements for direct Upon detection that the EAB SIB has NAS transport triggering and to support over- changed, the device performs an EAB check by load control and priority triggering. comparing the AC value stored in the device •Enhancements intended for monitoring of with the broadcasted bitmap. If the bit that cor- MTC devices, UE, and user/subscription related responds to the AC of the device is set, the events. This comprises of means that allow for device is barred and will not initiate any commu- activating monitoring of specific events, the nication until the EAB SIB has been changed event detection and the reporting to authorized and the corresponding bit has been changed. users (e.g., for use by applications or logging). There are different means to configure the Some examples of monitoring events are moni- device with low access priority, EAB, and addi- toring the association of the device and UICC, tional signaling reduction parameters, as dis- change in the point of attachment, and loss of cussed earlier. Besides the possibility of doing it connectivity. It is desired that the network be 34 IEEE Communications Magazine • November 2012C qM IEEE M ommunications q qM Previous Page | Contents | Zoom in | Zoom out | Front Cover | Search Issue | Next Page MqM q Qmags THE WORLD’S NEWSSTAND®
  • 8. C qM IEEE M ommunications q qM Previous Page | Contents | Zoom in | Zoom out | Front Cover | Search Issue | Next Page MqM q Qmags THE WORLD’S NEWSSTAND® able to detect such events and report them to the SCS or the AS for desired and/or predefined actions. •Device power consumptions optimizations to prevent battery drain (which results from, e.g., Bitmap 0-9 [0 0 0 0 1 1 1 frequent changes between idle and connected Bitmap 0-9 [1 1 1 1 1 0 0 EAB modes or too long periods in connected mode) Paging EAB Paging broadcast UE RACH indication broadcast indication preamble •Optimized handling of groups of MTC Device is barred devices/subscriptions. This can be, say, the ability to trigger a group of devices, the ability to enforce a QoS policy for a group of devices, or optimization of charging for groups of devices EAB check: barred? Barred? No that need to be aggregated into one bill to a sin- UE data Yes, AC0 = 1 Access available wait for change immediately gle customer. in EAB after CONCLUSIONS AC: 0 In this article we describe the architectural enhancements to 3GPP system to facilitate Figure 7. Extended access barring principle. machine type communications. We describe the architectural impacts due to device triggering, PS-only service provision, SMS in MME support, interworking subteam at WiMAX Forum, involved in design and development of ATM RAN reference implementation and a mechanism for overload and congestion for Intel Network Processors, and standardization of ATM control defined in Rel-10/Rel-11. The diverse Functional API at Network Processing Forum. Prior to Intel, nature of MTC application brings a challenge to he worked at Center for Development of Telematics (C- provide optimizations that have broader applica- DoT) in India where he led a team for design and develop- ment for Mobility Management and BSS Application bility. 3GPP has been careful in selecting and Protocol for GSM MSC/VLR and was key contributor to prioritizing key service requirements to provide technical evaluation and network configuration of C-DoT solutions with broader applicability such as MSC/VLR during launch of Indian Mobile Personal commu- smartphone applications. MTC work is ongoing nication Services (IMPCS) by Department of Telecommuni- cations, Government of India. He obtained his B.E. degree in future releases. In Rel-12, focus is on new with honors in Computer Science and Engineering from enhancements/optimizations that are intended Guru Jambheshwar University, India in 1997. for small data and device triggering enhance- ments, monitoring, UE power consumption opti- PETER HEDMAN (peter.hedman@ericsson.com) joined Erics- ________________ son in 2000 after previously working for the company for mizations, and support for MTC group feature. five years as a consultant within different areas such as Intelligent Networks and GSM/NMT Gateway development. ACKNOWLEDGMENTS Since joining Ericsson he has been attending 3GPP SA WG2 The authors would like to thank Devaki Chan- with a focus on work impacting the mobile devices such as GPRS, EPS, IMS and WiFi-3GPP access interactions. He dramouli for her valuable comments. received his Master’s in Computer Science from Lund Insti- tute of Technology. REFERENCES H ARIS Z ISIMOPOULOS (haris.zisimopoulos@zte.com.cn) ____________________ [1] 3GPP TS 23.682, “Architecture Enhancements to Facili- received his Dipl.Eng. degree in electrical and computer tate Communications with Packet Data Networks and engineering from Aristotle University of Thessaloninki, Applications.” Greece in 1998, and his M.S. degree in communications, [2] 3GPP TS 23.060, “General Packet Radio Service (GPRS); networks, and software from the University of Surrey, Unit- Service description; Stage 2.” ed Kingdom, in 2001. Following his graduation, from 2001 [3] 3GPP TS 44.018, “Mobile radio interface layer 3 specifi- tp 2006 he worked for Vodafone Group R&D in the United cation; Radio Resource Control (RRC) Protocol.” Kingdom and was involved in a variety of research projects [4] 3GPP TS 24.368, “Non-Access Stratum (NAS) configura- in the area of mobile data networking. During this time he tion Management Object (MO).” was also involved in standardization of enablers for mobile [5] 3GPP TS 31.102, “Characteristics of the Universal Sub- services in the Open Mobile Alliance (OMA) specifically for scriber Identity Module (USIM) Application.” presence, group management, and push-to-talk over cellu- [6] 3GPP TS 23.401, “General Packet Radio Service (GPRS) lar. From 2006 to 2008 he worked for IPWireless and was enhancements for Evolved Universal Terrestrial Radio involved in 3GPP standardization, attending the 3GPP SA Access Network (E-UTRAN) Access.” WG2 standardization with main interest in EPC, MBMS, and 3GPP/WiMAX interworking activities. From 2008 to BIOGRAPHIES 2011 he worked for Samsung Electronics Research Institute (SERI) representing Samsung Electronics in 3GPP SA WG2 PUNEET JAIN (puneet.jain@intel.com) is a lead systems archi- ____________ and being primarily involved in IMS activities, voice and tect in the Mobile and Communications Group at Intel, video continuity issues, and system improvements for MTC. where he is driving research and standardization on MAC, During this period he also attended ETSI TC M2M as the RAN, and end-to-end network architecture for mobile main Samsung delegate. He joined ZTE in 2011 and is cur- broadband technologies. He has over 15 years of experi- rently the main delegate in 3GPP SA WG2 and TSG SA. He ence in the telecom industry. He is an active contributor to is still technically involved in EPC developments, and specif- 3GPP SA WG2 and also rapporteur of MTC work item. In ically system enhancements for MTC activities as an active his previous roles at Intel, he was chair of WiMAX-3GPP contributor. IEEE Communications Magazine • November 2012 35C qM IEEE M ommunications q qM Previous Page | Contents | Zoom in | Zoom out | Front Cover | Search Issue | Next Page MqM q Qmags THE WORLD’S NEWSSTAND®

×