3GPP Tutorials via 'The SpecTools'

Some of you may have noticed that the new and revamped 3GPP website have recently started offering 3GPP specs and features tutorials via The SpecTools. There is quite a lot of useful information and most of it is premium but a lot is free as well.

So the new starters or those wishing to refresh their knowledge feel free to check this out:

http://www.thespectool.com/3gpp/index.php

The 3GPP release 8 IMS Implementation, Deployment & Testing workshop

The 3GPP release 8 IMS Implementation, Deployment & Testing workshop took place in Sophia Antipolis on 24-25 November 2010.

The event was attended by 70 delegates actively participating to the discussions.

Presenting companies included: Tel : A1 Telekom Austria, Alcatel Lucent, Codenomicon, Conformiq, Eircom, Elvior, ETSI, France Telecom, GSMA, Huawei, Huawei, Mobitel, NTT DoCoMo, SFR, Telecom Italia, TestingTech, TU Berlin, Wind, Wipro, ZTE.

Here are the highlights from the ETSI document:

Goals and Outcome for this workshop

Share exprience from IMS implementation

Highlight areas for further specifications, for

Standards and Testing

Learn of issues and possible resolutions

Comments from The IMS Network Testing Group

Develop IMS core network test specifications based upon 3GPP, for:

• Interoperability

• conformance

• network integration

Hold interoperability events (IMS Plugtests)

Coordinate with other organisations such as OMA, MSF, GSMA

Implementations

• Beyond small islands, second wave to replace unscalable, unmaintenable early VoIP systems

• Implementation options - Hybrid CS-GW for transition from CS to LTE, which already has 2 million subscribers on IMS/CS-GW/RNC

• Auto provisioning - to simplify complexity

• IMS functions must be implemented in the core – not in any access network, such as LTE, and can be used for non-Voice as well

Implementing RCS (Rich Communication Suite)

• RCS trial feedback - Good feedback from 400 trial users on RCS but difficult to configure SBC

• RCS implementations should include aggregation with SNS (Social Network Services)– eg contact list from Facebook

• Most appreciated feature of RCS is: - cross-operator interworking and compatibility with ordinary phones, not just smartphones

Specific Issues and Resolutions

• FAX – Delay and Jitter issues - FTTH will solve long delays etc

• Emergency and Lawful Intercept with IMS -There are standards and developed solutions available but Currently still falls back to CS /TDM

• Data Provisioning speed is important, to achieve no service interruption.

• 3GPP II-NNI: Inter-IMS Network to Network Interface - Two levels: Solx (service with control function) and Coix (connection – a pipe for media).

• “PathFinder” Global ENUM – like DNS for phone number; It is a solution to number portability and can optimise routing

About Services

• Most issues are Beyond IMS - integrating OSS/BSS, existing systems, inter-vendors interfaces

• IMS and IN - Pity the Standards did not bring IN and IMS close together; Need iFC enhancements, like in IN; Need to support combining services

• OTT and SNS dominate growth - occupies the minds of commercial people, GSMA-like services have slowed down

• Service layer (Wipro) – Telcos want one SDP to serve all - include IMS and non-IMS services, human and non-humans on NAB, context based, and charge only what is ‘consumed’

Testing Methods, Tools and Test Beds

• Integrate Conformance checking with interoperability testing

• Automation of interoperability trace checking – it can reduce costs by more than 50 % compared to manual validation

• Independent Test Bed- available EPC playground for prototyping applications

• Protocol message customisation tool - allows changing the message and customise the flow

• Security testing tool - testing by ‘fuzzing’, 100% TTCN free – everything is already build in

• IMS is a multi vendor environment - Testing and validation must be an integral part of the deployment process

Memorable Quotes

“IMS is a Journey, not a destination” (ALU)

“SDP is almost anything” (Matjas Bericic, Mobitel)

“Voice as an app versus Voice as a Service” is a challenge (Manuel Vexler, Huawei)

“IMS is not a box, it is a network” (Matjas Bericic, Mobitel)

“global ENUM is DNS for phone numbers” (Adrian Dodd, GSMA)

“Kill with one SIP” (Ari Takanen, Codenomicon)

“ IOP is the red thread running through the entire ETSI standards development process “ (Milan Zoric, ETSI)

All documents from this workshop is available at: http://docbox.etsi.org/Workshop/2010/201011_IMSWORKSHOP/

Network Improvements for Machine Type Communications (NIMTC)

I have blogged about M2M before here.

The Release 10 work item Network Improvements for Machine Type Communications – Stage 1 for NIMTC specified a number of requirements to make the network more suitable for machine type communications. Additional aspects need to be studied before proceeding with their potential inclusion in the normative work.

In the course of the Release 10 work item, it was decided to leave out MTC Device to MTC Device communications from Release 10. This because it was felt it was not possible to do it justice within the Release 10 time frame. Nevertheless, MTC Device to MTC Device communications are expected to become of major importance, especially with consumer devices communicating directly to each other. Therefore, this work item aims to study the network improvements requirements of MTC Device to MTC Device scenarios. A particular aspect of MTC Device to MTC Device scenarios is the identification and functionality needed to set up a connection towards a MTC Device. The IMS domain may provide a solution for this required functionality. In this case the impacts and requirements of MTC on IMS needs to be studied.

Additionally MTC Devices often act as a gateway for a capillary network of other MTC Devices or non-3GPP devices. These gateway MTC Devices may have specific requirements on the mobile network, which have not yet been taken into account in the Release 10 NIMTC work item. Study is needed to determine to what extent improvements are needed and can be specified by 3GPP for MTC Devices that act as a gateway for 'capillary networks' of other devices. Also alignment with what is specified by ETSI TC M2M on this aspect is needed.

Further optimisations may be possible for (groups of) MTC Devices that are co-located. An example of this could be a car with a number of different MTC Devices that always move along together. Optimisations for these kind of scenarios have been suggested, but have not yet been taken into account in the Release 10 NIMTC. Study is needed to determine to what extent network improvements can be specified for co-located MTC Devices.

Because of the different characteristics of Machine-Type Communications, the optimal network for MTC may not be the same as the optimal network for human to human communications. Optimisations of network selections and steering of roaming may be needed. Study is needed to determine to what extent improvements are needed on network selection and steering of roaming for MTC.

Many MTC applications use some kind of location tracking. E.g. the existing LCS framework could be used to provide location information for these kinds of MTC applications. Study is needed to determine to what extent improvements are needed for MTC location tracking.

MTC brings a new concept of a MTC User and MTC Server. So far little attention has been given to service requirements on the communication between the network and the MTC User/MTC Server. Also alignment with what is specified by ETSI TC M2M on that aspect is needed. Study is needed on what kind of service requirements are needed and can be specified by 3GPP.

The Objective of Study on enhancements for Machine-Type Communications item is to study additional requirements, use cases and functionality beyond that specified by the Release 10 NIMTC work item on the following aspects:

• network improvements for MTC Device to MTC Device communications via one or more PLMNs. Note: direct-mode communication between devices is out of scope.

• possible improvements for MTC Devices that act as a gateway for 'capillary networks' of other devices. Note: capillary networks themselves are out of scope of 3GPP.

• network improvements for groups of MTC Devices that are co-located with other MTC Devices

• improvements on network selection mechanisms and steering of roaming for MTC devices

• possible enhancements to IMS to support MTC

• possible improvements for location tracking of MTC Devices

• service requirements on communications between PLMN and the MTC User/MTC Server (e.g. how the MTC User can set event to be monitored with MTC Monitoring);

• possible service requirements to optimize MTC Devices

• possible New MTC Features to further improve the network for MTC

The results of the study will be recorded in a Technical Report. Work ongoing in external standard organization shall be considered (e.g. ETSI M2M, CCSA TC 10).

The European Telecommunications Standards Institute (ETSI) now has a Technical Committee exclusively focused on M2M; the Chinese Communications Standards Association (CCSA) is currently exploring the definition of M2M standards for China and the Geneva-headquartered International Telecommunications Union (ITU) is working on “mobile wireless access systems providing telecommunications for a large number of ubiquitous sensors and/or actuators scattered over wide areas in the land mobile service,” which are at the center of the M2M ecosystem.

Closer to us, the US Telecommunications Industry Association (TIA) has also launched a new engineering committee centered on Smart Device Communications (TIA TR-50). Incidentally, at Global Standards Collaboration 15 (GSC-15), which will be held on August 30- September 2, 2010 in Beijing and hosted by CCSA, the world’s leading telecommunications and radio standards organizations will meet to promote innovation and collaboration on a broad spectrum of standards topics among which M2M has been identified as a “High Interest Subject.”

Related subject on 3GPP here.

M2M workshop is happening in ETSI next week. More details here.

Definitions:

MTC Device: A MTC Device is a UE equipped for Machine Type Communication, which communicates through a PLMN with MTC Server(s) and/or other MTC Device(s).

Local-Access Device: A Local-Access Device is a device in MTC Capillary Network, which has no 3GPP mobile communication capability.

MTC Capillary Network: An MTC Capillary Network is a network of devices that provides local connectivity between devices within its coverage and MTC Gateway Device.

MTC Gateway Device: An MTC Gateway Device is an MTC device equipped for Machine Type Communication, which acts as a gateway for a group of co-located MTC Devices or to connect MTC Devices and/or Local-Access Devices in an MTC Capillary Network to communicate through a PLMN with MTC Server(s), and/or other MTC Device(s).

Further Interesting Reading:

The M2M Switch - turning the wireless business model upside down

MARKET FOR M2M APPLICATIONS EXPLODES

Embedded Mobile M2M Modem Market on Track to More Than Triple in 2010

3GPP Green activities / Energy Saving initiatives

3GPP has been working on Energy saving initiatives for Release-10 and Release-11. Here is a very quick summary of some of these items.

Telecommunication management; Study on Energy Savings Management (ESM)

Most mobile network operators aim at reducing their greenhouse emissions, by several means such as limiting their networks' energy consumption.

In new generation Radio Access Networks such as LTE, Energy Savings Management function takes place especially when mobile network operators want e.g. to reduce Tx power, switch off/on cell, etc. based on measurements made in the network having shown that there is no need to maintain active the full set of NE capabilities.

By initiating this Work Item about Energy Savings Management, 3GPP hopes to contribute to the protection of our environment and the environment of future generations.

The objective of this technical work is to study automated energy savings management features. Usage of existing IRPs is expected as much as possible, e.g. Configuration Management IRP, etc. However, this technical work may identify the need for defining a new IRP.

The following operations may be considered in this study item (but not necessarily limited to):
• Retrieval of energy consumption measurements
• Retrieval of traffic load measurements
• Adjust Network Resources capabilities


OAM aspects of Energy Saving in Radio Networks

There are strong requirements from operators on the management and monitoring of energy saving functions and the evaluation of its impact on the network and service quality. Therefore an efficient and standardized Management of Energy Saving functionality is needed. Coordination with other functionalities like load balancing and optimization functions is also required.

The objectives of this work item are:
• Define Energy Savings Management OAM requirements and solutions for the following use cases,
• eNodeB Overlaid
• Carrier restricted
• Capacity Limited Network
• Define OAM requirements and solutions for coordination of ESM with other functions like
• Self-Optimization
• Self Healing
• Traditional configuration management
• Fault Management
• Select existing measurements which can be used for assessing the impact and effect of Energy Saving actions corresponding to above Energy Saving use cases.
• Define new measurements which are required for assessing the impact and effect of Energy Saving actions, including measurements of the energy consumption corresponding to above Energy Saving use cases.


Study on impacts on UE-Core Network signalling from Energy Saving

Energy Saving (ES) mechanisms are becoming an integral part of radio networks, and consequently, of mobile networks. Strong requirements from operators (for reasons of cost and environmental image) and indirectly from authorities (for the sake of meeting overall international and national targets) have been formulated. With the expected masses of mobile network radio equipment as commodities, in the form of Home NB/eNBs, this aspect becomes even more crucial.

It is necessary to ensure that ES does not lead to service degradation or inefficiencies in the network. In particular:
• the activation status of radio stations (on/off) introduces a new scale of dynamicity for the UE and network;
• mass effects in signalling potentially endanger the network stability and need to be handled properly.

It is unclear whether and how currently defined procedures are able to cope with, and eventually can be optimized for, ES conditions; thus a systematic study is needed.

The study aims, within the defined CT1 work areas, at:
• analysing UE idle mode procedures and UE-Core Network signalling resulting from frequent switch on/off of radio equipment in all 3GPP accesses, including home cell deployment and I-WLAN;
• performing a corresponding analysis for connected mode UEs;
• analysing similar impacts from activation status of non-3GPP access networks;
• documenting limitations, weaknesses and inefficiencies in these procedures, with emphasis on mass effects in the UE-Core Network signalling;
• studying potential optimizations and enhancements to these procedures;

The study shall also evaluate and give recommendations on potential enhancements to 3GPP specifications (whether and where they are seen necessary).


Study on Solutions for Energy Saving within UTRA Node B

Due to the need to reduce energy consumption within operators’ networks, and considering the large amount of UMTS network equipment deployed in the field around the world, the standardisation of methods to save energy in UMTS Node Bs is seen as an important area of study for 3GPP.There has not been a large amount of focus on energy-saving in UMTS networks so far in 3GPP, although some solutions have been agreed in Release 9. Therefore it is proposed to start an initial study phase to identify solutions and perform any initial evaluation, such that a subset of these proposals can be used as the basis for further investigation of their feasibility.

The objective is to do an initial study to identify potential solutions to enable energy saving within UMTS Node-Bs, and do light initial evaluation of the proposed solutions, with the aim that a subset of them can be taken forward for further investigation as part of a more focused study in 3GPP.

The solutions identified in this study item should consider the following aspects:
• Impacts on the time for legacy and new UEs to gain access to service from the Node B
• Impacts on legacy and new terminals (e.g. power consumption, mobility)

Some initial indication of these aspects in relation to the proposed solutions should be provided.


Study on Network Energy Saving for E-UTRAN

The power efficiency in the infrastructure and terminal should be an essential part of the cost-related requirements in LTE-A. There is a strong need to investigate possible network energy saving mechanisms to reduce CO2 emission and OPEX of operators.

Although some solutions have been proposed and part of them have been agreed in Release-9, there has not been a large amount of attention on energy saving for E-UTRAN so far. Many potential solutions are not fully shown and discussed yet. Therefore, it is proposed to start an initial study phase to identify solutions, evaluate their gains and impacts on specifications.

The following use cases will be considered in this study item:
• Intra-eNB energy saving
• Inter-eNB energy saving
• Inter-RAT energy saving

Intra-eNB energy saving, in EUTRAN network, a single cell can operate in energy saving mode when the resource utilization is sufficiently low. In this case, the reduction of energy consumption will be mainly based on traffic monitoring with regard to QoS and coverage assurance.

A lot of work on Inter-eNB energy saving has already been done for both LTE and UTRA in Rel-9. This Study Item will investigate additional aspects (if any) on top of what was already agreed for R9.

Inter-RAT energy saving, in this use case, legacy networks, i.e. GERAN and UTRAN, provide radio coverage together with E-UTRAN. For example E-UTRAN Cell A is totally covered by UTRAN Cell B. Cell B is deployed to provide basic coverage of the voice or medium/low-speed data services in the area, while Cell A enhances the capability of the area to support high-speed data services. Then the energy saving procedure can be enabled based on the interaction of E-UTRAN and UTRAN system.

The objective of this study item is to identify potential solutions for energy saving in E-UTRAN and perform initial evaluation of the proposed solutions, so that a subset of them can be used as the basis for further investigation and standardization.

Energy saving solutions identified in this study item should be justified by valid scenario(s), and based on cell/network load situation. Impacts on legacy and new terminals when introducing an energy saving solution should be carefully considered. The scope of the study item shall be as follows:
• User accessibility should be guaranteed when a cell transfers to energy saving mode
• Backward compatibility shall be ensured and the ability to provide energy saving for Rel-10 network deployment that serves a number of legacy UEs should be considered
• Solutions shall not impact the Uu physical layer
• The solutions should not impact negatively the UE power consumption

RAN2 will focus on the Intra-eNB energy saving, while RAN3 will work on Inter-RAT energy saving and potential additional Inter-eNB energy saving technology.


Study on Solutions for GSM/EDGE BTS Energy Saving

There has not been a large amount of focus on energy-saving in GSM/EDGE networks so far in 3GPP, although some solutions have been agreed in previous Releases, notably MCBTS. Therefore it is proposed to start an initial study phase to identify solutions and perform any initial evaluation, such that a subset of these proposals can be used as the basis for further investigation of their feasibility.

The objective is to study potential solutions to enable energy saving within the BTS (including MCBTS and MSR), and evaluate each proposed solutions in detail. These potential solutions shall focus on the following specific aspects
• Reduction of Power on the BCCH carrier (potentially enabling dynamic adjustment of BCCH power)
• Reduction of power on DL common control channels
• Reduction of power on DL channels in dedicated mode, DTM and packet transfer mode
• Deactivation of cells (e.g. Cell Power Down and Cell DTX like concepts as discussed in RAN)
• Deactivation of other RATs in areas with multi-RAT deployments, for example, where the mobile station could assist the network to suspend/minimise specific in-use RATs at specific times of day
• And any other radio interface impacted power reduction solutions.

The solutions identified in this study item shall also consider the following aspects:
• Impacts on the time for legacy and new mobile stations to gain access to service from the BTS
• Impacts on legacy and new mobile stations to keep the ongoing service (without increasing drop rate)
• Impacts on legacy and new mobile stations implementation and power consumption, e.g. due to reduction in DL power, cell (re-)selection performance, handover performance, etc.
• Impacts on UL/DL coverage balance, especially to CS voice

Solutions shall be considered for both BTS energy saving non-supporting and supporting mobile stations (i.e. solutions that are non-backwards compatible towards legacy mobile stations shall be out of the scope of this study).

1200Mbps DL with LTE-Advanced

I blogged last year about the LTE-A UE categories but then the categories were still under discussion. In the 3GPP RAN WG1#62 LTE-Advanced UE Categories were discussed based on NTT DoCoMo proposal and the data rates are as summarised in the picture above.

Note that category 8 has 1200Mbps DL and 600Mbps UL speed.

The complete report is available here.

Via: WirelessMoves.

3GPP and 3G Americas workshop in Latam LTE Summit

3GPP and 3G Americas held a LTE Standards workshop in advance of this years’ LTE Latin America Conference, held in Rio de Janeiro 26-28 April.

Speakers from Operators and Manufacturers’ looked at the huge potential for HSPA and LTE networks and discussed Standards and Regulatory issues that are affecting LTE Roadmaps for the Latin America Region.

Topics such as equipment availability and spectrum scarcity were high on the agenda, along with discussions on systems architecture evolution and backhaul issues.

The presentations from the workshop are available on-line HERE.

Individual presentations could be downloaded from the links below:

• Operator Presentations
  

  • VIVO - Oportunidades e Desafios Banda Larga Móvel no Brasil
    
  • CLARO - Operator Strategies for Mobile Broadband
    
  • NTT DOCOMO - RAN Migration Strategy

  
  
• Manufacturers’ Presentations
  
  • Ericsson - Perspective Setorial de HSPA Evoluido
    
  • NSN - Migrating from HSPA to HSPA+ and LTE
  
  
• 3GPP and 3G Americas Presentations
  
  • Marketplace update
    Spectrum Policy and Recommendations
    
  • 3GPP Standards Roadmap

Operator Top Ten Requirements for the networks

Operation Requirements for next generation multi-technology networks are the key topic that brought 3GPP, NGMN and TM Forum together for a workshop held March 29-30 2010 in Bonn. The two-day workshop was attended by forty industry experts who worked on use cases and requirements in three parallel work streams and provided recommendations for next steps.

At the Bonn workshop, the 3GPP Telecom Management working group - SA5 - presented background data on the SA5 work program to date, much of which meets the needs of the NGMN Top Ten Requirements:

• Quality and Quantity of Alarms
• Automatic Software Management
• Energy Saving
• LTE Automatic Neighbour Relation (ANR) and Self Organizing Networks (SON) Operation
• Performance Management in Real-time
• Substitution of Monitoring Probes by Infrastructure Inherent Trace Functionality
• eNodeB Plug & Play Self-Commissioning
• OSS Standard Itf-N
• LTE Parameter Optimization
• Automatic Inventory

The workshop conclusions acknowledged that:

• Standards specified by SA5 over the last ten years provide a widely deployed, fully re-usable and expandable solution for management of Next Generation Networks,
• NGMN Top Ten Requirements are mostly satisfied already by 3GPP SA5 specifications, the missing functionalities will be addressed in 3GPP Release 10 (due December 2010),
• The ongoing 3GPP-TMF alignment program provides an excellent opportunity to address network management of Wireless-Wireline convergence based on the 3GPP IRP framework.

At the end of this workshop, the SA5 Chairman Christian Toche said:

"This workshop has identified important requirements and allowed TMF and 3GPP to compare their solutions that can satisfy Operators requirements, of whom many are already supported in 3GPP specifications. I am confident that, as long as the representation from each group is maintained at the right level, an alignment of the 3GPP and TM Forum specifications will result from this cooperation, satisfying the requirements for use in convergent network operational environment."

Christian Toche identified that the next step includes the need for the two ongoing Network Management harmonization projects with the TM Forum - On FM and resource modelling - to be completed.

Further progress on the alignment of 3GPP and TMF specifications will be made at the follow-up workshop on May 6-7, 2010 in Montreal

3GPP documents from Bonn workshop are available at: ftp://ftp.3gpp.org/tsg_sa/WG5_TM/Ad-hoc_meetings/2010-05-Top_10/Docs/S5w100004.zip

3GPP Technology Standards Roadmap

New presentation from Stephen Hayes, Chair 3GPP-SA available on the 3GPP website. Click here.

3GPP and Broadband Forum Collaboration on Fixed Mobile Convergence Standards

Fixed/Mobile Convergence (FMC) was the key topic that brought 3GPP and the Broadband Forum together for their first joint workshop, held February 18-19 in San Francisco. The two-day workshop was attended by 120 industry experts, who reviewed over 40 contributions focused primarily on use cases and joint requirements.

The attendees, primarily 3GPP and Broadband Forum members, also included representatives from ETSI TISPAN, ATIS and other standards bodies. The diverse group came together with a shared goal; to start the process of aligning new FMC work in each organization to best address both fixed and wireless management requirements. The two days spent together allowed the group to identify the key issues at hand and the work that needs to be done. With words of appreciation and encouragement from workshop co-chairs, Stephen Hayes of 3GPP and Dave Allan of the Broadband Forum, each organization took away work items that address both near term and long term next steps for both 3GPP and the Broadband Forum.


Through liaison communications and technical contributions into each organization, joint requirements will be shared, and another workshop is envisioned for the future after a scope and gap analysis is performed by the organizations.

Workshop documents and presentations are at available…on line

Presentations & Papers from the Workshop:

• Beyond FMC Interworking UDC for FMC
• Proposed Use Case and Requirement based on Policy Control in FMC
• Proposed Architecture for Policy Control in FMC
• Seamless WLAN offload
• 3GPP EPC Overview
• Broadband Forum Status (Revised version)
• 3GPP-BBF Interworking - Mobility-Roaming-Nomadism (See Workshop docs for various revisions of this document – Last version)
• 3GPP-BBF Interworking - Authentication/Authorization/Accounting
• 3GPP-BBF Interworking Policy & QoS
• High level analysis of Interworking between fixed NW access and 3GPP domain
• ATIS’ Organizational Efforts on FMC
• ATIS Exploratory Group on Convergence (EGC) Report & Recommendations
• 3GPP-BBF Interworking - Use Cases for Public and Enterprise Wireline Interworking
• 3GPP-BBF Interworking - S9 Interface: Requirements and Protocol Selection Criteria
• 3GPP-BBF Interworking - Proposal for PCRF Based BPCF
• Media and Codec policies architecture with converged Next Generation Networks
• Focus on working procedures for the policy control aspect of FMC
• PCRF-BPCF Functional Split and Information Exchange
• View on FMC – Policy Control
• ETSI TISPANPolicy Management Overview
• 3GPP Work Item Description - Support for BBF Accesses Interworking
• WT-203 - Interworking between next Generation Fixed and 3gpp wireless access
• Fixed Mobile Interworking - QoS Control via S9
• Policy Interworking – How to setup QoS for a 3GPP UE in a BBF domain
• Fixed Mobile Interworking - Establishing the s9 Session
• Connectivity and Mobility Considerations
• Authenticaton Conundrum
• TISPAN Policy Management Overview
• 3GPP-BBF Architecture - Mobility aspects
• Change Request to 3GPP Technical Specification 22.278 - Addition of operational requirements for Fixed Mobile Convergence
• Key Workshop findings

Takehiro Nakamura on LTE Radio Aspects

In summary:

Release 8 - Minor change requests to it based on March 2009 freeze;
Release 9 - an enhanced version of Release 8 and additional features;
Release 10 (LTE-Advanced) - proposed as an IMT-Advanced and is expected to be approved by December 2010; major differences between LTE and LTE-Advanced

Via: LTE Portal

3GPP IMT-Advanced Workshop in Beijing

3GPP technical experts have attended the recent IMT-Advanced workshop, in Beijing, China, hosted by the China MIIT Institute of Communication Standards Research (CATR) and China Mobile.

The workshop was chaired by the 3GPP TSG RAN chairman, Takehiro Nakamura, with the first day given over to 3GPP RAN working group presentations and the second to the twelve IMT-Advanced evaluation groups.

3GPP Presentations:

• LTE technologies (Takehiro Nakamura: TSG-RAN Chair, NTT DOCOMO)
• Physical layer aspects (Matthew Baker: RAN WG1 Chair, Alcatel-Lucent)
• Layer 2 and 3 aspects (Magnus Lindström: RAN WG2, Ericsson)
• RAN architecture aspects (Dino Flore: RAN WG3 Chair, Qualcomm)
• RF aspects (Takaharu Nakamura: RAN WG4 Chair, Fujitsu)
• 3GPP Self evaluation methodology and results (Tetsushi Abe: RAN WG1 Vice-Chair, NTT DOCOMO)

Status reports from the IMT-Advanced Independent Evaluation Groups (IEG):

• ARIB
• ATIS WTSC Evaluation Group
• CEG
• ChEG (Part I) (Part II)
• ETSI
• REG
• TCOE India
• TR 45 (Presentation not available)
• TTA PG707
• WFEG
• WINNER+ (Part I)(Part II

You can view the agenda of the workshop here.

You can also check all the documents directly here.

LTE = Windows Vista and HSPA = Windows XP

Moray Rumney in Forum Oxford made us aware that 3GPP has published a link on their homepage to address concerns with aspects of LTE deployment covering:

• Support for voice
• Supoort for SMS
• Readiness of IMS
• Support for emergency calling

Dean Bubley, a well known analyst provided the following response:

It takes a very narrow view that "maturity" equals "fully specified". It still maintains that "The voice solution for LTE is IMS VoIP and it is fully specified" and that any other solution is merely a "transition".

In other words, it makes LTE sound unsuitable for those operators which are IP-centric but which do not believe in IMS as a suitable control/service solution.

3GPP is trying to use LTE as a lever to force unwilling operators to adopt IMS. This will fail.

SMS-over-SGs has some serious shortcoming as well as costs, but is probably OK as a short term solution.

I am moving to the view that current LTE is the equivalent of Windows Vista, while HSPA = XP

I think a lot of operators will wait until "Windows 7" becomes available, either LTE Advanced or perhaps Rel 10 LTE.

Very interesting. He has put forward a great analogy of Windows OS that reflects concerns of many of us.

You can follow the complete discussions here.

IMT-Advanced Proposals by 3GPP and IEEE

The proposals for IMT-Advanced that I mentioned about earlier have been put up on 3G4G website.

The 3GPP proposal for LTE-Advanced is here.

The IEEE proposal for 802.16m is here.

IMT-Advanced Proposals to be discussed next week

Depending on which camp you belong to, you would have read atleast one press release.

The 3GPP Partners, which unite more than 370 leading mobile technology companies, made a formal submission to the ITU yesterday, proposing that LTE Release 10 & beyond (LTE-Advanced) be evaluated as a candidate for IMT-Advanced. Complete press release here.

The IEEE today announced that it has submitted a candidate radio interface technology for IMT-Advanced standardization in the Radiocommunication Sector of the International Telecommunication Union (ITU-R).

The proposal is based on IEEE standards project 802.16m™, the “Advanced Air Interface” specification under development by the IEEE 802.16™ Working Group on Broadband Wireless Access. The proposal documents that it meets ITU-R’s challenging and stringent requirements in all four IMT-Advanced “environments”: Indoor, Microcellular, Urban, and High Speed. The proposal will be presented at the 3rd Workshop on IMT-Advanced in Dresden on 15 October in conjunction with a meeting of ITU-R Working Party 5D. Complete press release here.

The workshop next week will see lots of announcements, discussions and debates about both these technologies. More details on workshop here. My 3G4G page on LTE-Advanced here.

I am sure there is a place for both these technologies and hopefully both of them will succeed :)

Femtocells Standardization in 3GPP

Femtocells have been around since 2007. Before Femtocells, the smallest possible cell was the picocell that was designed to serve a small area, generally a office or a conference room. With Femtocells came the idea of having really small cells that can be used in houses and they were designed to serve just one home. Ofcourse in my past blogs you would have noticed me mentioning about Super Femtos and Femto++ that can cater for more users in a small confined space, typically a small office or a meeting room but as far as the most common definition is concerned they are designed for small confined spaces and are intended to serve less than 10 users simultaneously.

This blog post is based on IEEE paper on "Standardization of Femtocells in 3GPP" that appeared in IEEE Communications Magazine, September 2009 issue. This is not a copy paste article but is based on my understanding of Femtos and the research based on the IEEE paper. This post only focusses on 3GPP based femtocells, i.e., Femtocells that use UMTS HSDPA/HSPA based technology and an introduction to OFDM based LTE femtocells.

The reason attention is being paid to the Femtocells is because as I have blogged in the past, there are some interesting studies that suggest that majority of the calls and data browsing on mobiles originate in the home and the higher the frequency being used, the less its ability to penetrate walls. As a result to take advantage of the latest high speed technologies like HSDPA/HSUPA, it makes sense to have a small cell sitting in the home giving ability to the mobiles to have high speed error free transmission. In addition to this if some of the users that are experiencing poor signal quality are handed over to these femtocells, the overall data rate of the macro cell will increase thereby providing better experience to other users.

Each technology brings its own set of problems and femocells are no exception. There are three important problems that needs to be answered. They are as follows:

• Radio interference mitigation and management: Since femtocells would be deployed in adhoc manner by the users and for the cost to be kept down they should require no additional work from the operators point of view, they can create interference with other femtocells and in the worst possible scenario, with the macro cell. It may not be possible initially to configure everything correctly but once operational, it should be possible to adjust the parameters like power, scrambling codes, UARFCN dynamically to minimise the interference.

• Regulatory aspects: Since the mobiles work in licensed spectrum bands, it is required that they follow the regulatory laws and operate in a partcular area in a band it is licensed. This is not a problem in Europe where the operators are given bands for the whole country but in places like USA and India where there are physical boundaries within the country for the allocation of spectrum for a particular operator. This brings us to the next important point.

• Location detection: This is important from the regulatory aspect to verify that a Femtocell can use a particular band over an area and also useful for emergency case where location information is essential. It is important to make sure that the user does not move the device after initial setup and hence the detection should be made everytime the femto is started and also at regular intervals.

3GPP FEMTOCELLS STANDARDIZATION

Since the femtocells have been available for quite a while now, most of them do not comply to standards and they are proprietary solutions. This means that they are not interoperable and can only work with one particular operator. To combat this and to create economy of scale, it became necessary to standardise femtocells. Standardized interfaces from the core network to femtocell devices can potentially allow system operators to deploy femtocell devices from multiple vendors in a mix-and-match manner. Such interfaces can also allow femtocell devices to connect to gateways made by multiple vendors in the system operator’s core network (e.g., home NodeB gateway [HNB-GW] devices).

In 2008, Femto Forum was formed and it started discussion on the architecture. From 15 different proposals, consensus was reached in May over the Iuh interface as shown below.

There are two main standard development organizations (SDOs) shaping the standard for UMTS-related (UTRAN) femto technology: 3GPP and The Broadband Forum (BBF).
More about 3GPP here. BBF (http://www.broadbandforum.org) was called the DSL Forum until last year. As an SDO to meet the needs of fixed broadband technologies, it has created specifications mainly for DSL-related technologies. It consists of multiple Working Groups. The Broadband Home WG in particular is responsible for the specification of CPE device remote management. The specification is called CPE wide area network (WAN) Management Protocol (CWMP), which is commonly known by its document number, TR-069.

There are several other important organisations for femto technology. The two popular ones are the Femto Forum (www.femtoforum.org) and Next Generation Mobile Network (NGMN).

3GPP has different terminology for Femtocells and components related to that. They are as follows:

Generic term: Femtocell
3GPP Term: home NodeB (HNB)
Definition: The consumer premises equipment (CPE) device that functions as the small-scale nodeB by interfacing to the handset over the standard air interface (Uu) and connecting to the mobile network over the Iuh interface.

Generic term: FAP Gateway (FAP-GW) or Concentrator
3GPP Term: home NodeB gateway (HNB-GW)
Definition: The network element that directly terminates the Iuh interface with the HNB and the existing IuCS and IuPS interface with the CN. It effectively aggregates a large number of HNBs (i.e., Iuh interface) and presents it as a single IuCS/PS interface to the CN.

Generic term: Auto-Configuration Server (ACS)
3GPP Term: home NodeB management system (HMS)
Definition: The network element that terminates TR-069 with the HNB to handle the remote management of a large number of HNBs.

In addition, there is a security gateway (SeGW) that establishes IPsec tunnel to HNB. This ensures that all the Iuh traffic is securely protected from the devices in home to the HNB-GW.
The HNB-GW acts as a concentrator to aggregate a large number of HNBs which are logically represented as a single IuCS/IuPS interface to the CN. In other words, from the CN’s perspective, it appears as if it is connected to a single large radio network controller (RNC). This satisfies a key requirement from 3GPP system operators and many vendors that the femtocell system architecture not require any changes to existing CN systems.

The radio interface between HNB and UE is the standard RRC based air interface but has been modified to incude HNB specific changes like the closed subscriber group (CSG) related information.

Two new protocols were defined to address HNB-specific differences from the existing Iu interface protocol to 3GPP UMTS base stations (chiefly, RANAP at the application layer).

• HNB Application Protocol (HNBAP): An application layer protocol that provides HNB-specific control features unique to HNB/femtocell deployment (e.g., registration of the HNB device with the HNBGW).

• RANAP User Adaptation (RUA): Provides a lightweight adaptation function to allow RANAP messages and signaling information to be transported directly over Stream Control Transport Protocol (SCTP) rather than Iu, which uses a heavier and more complex protocol stack that is less well suited to femtocells operating over untrusted networks from home users (e.g., transported over DSL or cable modem connections).

Figure above is representation of the protocol stack diagram being used in TS 25.467.

Security for femtocell networks consists of two major parts: femtocell (HNB) device authentication, and encryption/ciphering of bearer and control information across the untrusted Internet connection between the HNB and the HNB-GW (e.g., non-secure commercial Internet service). The 3GPP UMTS femtocell architecture provides solutions to both of these problems. 3GPP was not able to complete the standardization of security aspects in UMTS Release 8; however, the basic aspects of the architecture were agreed on, and were partially driven by broad industry support for a consensus security architecture facilitated in discussions within the Femto Forum. All security specifications will be completed in UMTS Release 9 (targeted for Dec. 2009).

FEMTOCELL MANAGEMENT

Management of femtocells is a very big topic and very important one for the reasons discussed above.

The BBF has created CWMP, also referred to as TR-069. TR-069 defines a generic framework to establish connection between the CPE and the automatic configuration server (ACS) to provide configuration of the CPE. The messages are defined in Simple Object Access Protocol (SOAP) methods based on XML encoding, transported over HTTP/TCP. It is flexible and extensive enough to incorporate various types of CPE devices using various technologies. In fact, although TR-069 was originally created to manage the DSL gateway device, it has been adopted by many other types of devices and technologies.

The fundamental functionalities TR-069 provides are as follows:

• Auto-configuration of the CPE and dynamic service provisioning

• Software/firmware management and upgrade

• Status and performance monitoring

• Diagnostics

The auto-configuration parameters are defined in a data model. Multiple data model specifications exist in the BBF in order to meet the needs of various CPE device types. In fact, the TR-069 data model is a family of documents that has grown over the years in order to meet the needs of supporting new types of CPE devices that emerge in the market. In this respect, femtocell is no exception. However, the two most common and generic data models are:

• TR-098: “Internet Gateway Device Data Model for TR-069”

• TR-106: “Data Model Template for TR-069-Enabled Devices”

HAND-IN AND FEMTO-TO-FEMTO HANDOVERS

The 3GPP specifications focused on handovers in only one direction initially — from femtocell devices to the macrocellular system (sometimes called handout). A conscious decision was made to exclude handover from the macrocellular system to the femtocell devices (sometimes called macro to femtocell hand-in). This decision was driven by two factors:

• There are a number of technical challenges in supporting hand-in with unmodified mobile devices and core network components.

• The system operator requirements clearly indicate that supporting handout is much more important to end users.

Nonetheless, there is still a strong desire to develop open, interoperable ways to support handin in an efficient and reliable manner, and the second phase of standards in 3GPP is anticipated to support such a capability.

NEXT-G EFFORTS

3GPP Release 8 defines the over-the-air radio signaling that is necessary to support LTE femtocells. However, there are a number of RAN transport and core network architecture, interface, and security aspects that will be addressed as part off 3GPP’s Release 9 work efforts. While it is preliminary as of the publication of this article, it seems highly likely that all necessary RAN transport and core network work efforts for LTE femtocells will be completed in 3GPP Release 9 (targeted for completion by the end of 2009).

3GPP STANDARDS ON FEMTOCELLS

[1] 3GPP TS 25.331: RRC

[2] 3GPP TS 25.367: Mobility Procedures for Home NodeB (HNB); Overall Description; Sage 2

[3] 3GPP TS 25.467: UTRAN Architecture for 3G Home NodeB; Stage 2

[4] 3GPP TS 25.469: UTRAN Iuh Interface Home NodeB (HNB) Application Part (HNBAP) Signaling

[5] 3GPP TS 25.468: UTRAN Iuh Interface RANAP User Adaption (RUA) Signaling

[6] 3GPP TR 3.020: Home (e)NodeB; Network Aspects -(http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/R3_internal_TRs/R3.020_Home_eNodeB/)

[7] 3GPP TS 25.104: Base Station (BS) Radio Transmission and Reception (FDD)

[8] 3GPP TS 25.141: Base Station (BS) Conformance Testing (FDD)

[9] 3GPP TR 25.967: FDD Home NodeB RF Requirements

[10] 3GPP TS 22.011: Service Accessibility

[11] 3GPP TS 22.220: Service Requirements for Home NodeB (HNB) and Home eNodeB (HeNB)

[12] 3GPP TR 23.830: Architecture Aspects of Home NodeB and Home eNodeB

[13] 3GPP TR 23.832: IMS Aspects of Architecture for Home NodeB; Stage 2

[14] 3GPP TS 36.300: E-UTRA and E-UTRAN; Overall Description; Stage 2

[15] 3GPP TR 33.820: Security of H(e)NB 3GPP TR 32.821: Telecommunication Management; Study of Self-Organizing Networks (SON) Related OAM Interfaces for Home NodeB

[16] 3GPP TS 32.581: Telecommunications Management; Home Node B (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Concepts and Requirements for Type 1 Interface HNB to HNB Management System (HMS)

[17] 3GPP TS 32.582: Telecommunications Management; Home NodeB (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Information Model for Type 1 Interface HNB to HNB Management System (HMS)

[18] 3GPP TS 32.583: Telecommunications Management; Home NodeB (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Procedure Flows for Type 1 Interface HNB to HNB Management System (HMS)

[19] 3GPP TS 32.584: Telecommunications Management; Home NodeB (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); XML Definitions for Type 1 Interface HNB to HNB Management System (HMS)

I would strongly recommend reading [3] and [6] for anyone who wants to gain better understanding of how Femtocells work.