What is RedCap UE?
4 hours ago
Tuesday, 30 November 2010
Monday, 29 November 2010
LSTI: Job nearly done!
According to Mobile Europe magazine, LSTI has nearly completed the tasks it had been created for. The following is from the report:
LSTI said it has reached Milestones for Interoperability Development Tests (IODT), Interoperability Tests (IOT) and for Friendly Customer Trials (FCT). With these Milestones complete, LSTI said it could move to its last working phase and "finish all LTE trials in a timely manner".
Following on from the Proof of Concept (PoC) tests, which was the first testing phase of the LSTI alliance, and which was completed a year ago, LSTI has now completed all Interoperability Development Tests (IODT) for both FDD (Frequency Division Duplex) and TDD (Time-Division Duplex). Furthermore, penultimate Milestone for Interoperability Tests (IOT) has also been passed. That means that the LSTI members have proved that at least three vendors for each case are about to deliver to the market interoperability tested access network and terminal equipment.
The Core Network Interface S1 (Connection Access Network to Core) IOT is almost completed and more results are expected to be delivered soon.
“Overall these results are well aligned with the previous results shared in the LSTI PoC phase. This testing and the co-operation of the vendors and operators involved have brought forward the growth of the LTE ecosystem and enabled a accelerated commercialisation of LTE-EPC by fostering technology alignment across all parties”, said Christian Kuhlins, LSTI Activity Manager IOT, Ericsson AB. “We can now see that the telecommunications industry is about to launch LTE/SAE equipment. More and more commercial network and terminal equipment will be available on the market very soon.”
Eleven LSTI operators have set-up their LTE/EPC trials and have already delivered reports built on a common testing methodology. The Trial Group has achieved one major step in passing the “Radio Access Testing” milestone which includes: Latency, State Transition, Throughput, Cell Capacity, Mobility, Basic Quality of Service and User Experience testing domains.
LSTI said that last results are expected during the next few weeks and will be presented at the Mobile World Congress 2011.
LSTI Updates from Oct. 2010
View more presentations from Zahid Ghadialy.
Friday, 26 November 2010
Iridium NEXT: Next Generation Satellite Network
Iridium Everywhere
View more presentations from Zahid Ghadialy.
To download see: http://www.cambridgewireless.co.uk
Thursday, 25 November 2010
LIPA, SIPTO and IFOM Comparison
Enhancing macro radio access network capacity by offloading mobile video traffic will be essential for mobile communications industry to reduce its units costs to match its customer expectations. Two primary paths to achieve this are the use of femtocells and WiFi offloading. Deployment of large scale femtocells for coverage enhancement has been a limited success so far. Using them for capacity enhancements is a new proposition for mobile operators. They need to assess the necessity of using them as well as decide how to deploy them selectively for their heavy users.
Three alternative architectures that are being standardized by 3GPP have various advantages and shortcomings. They are quite distinct in terms of their dependencies and feasibility. Following table is a summary of comparison among these three approaches for traffic offloading.
Looking at the relative strengths of the existing traffic offload proposals, it is difficult to pick an outright winner. SIPTO macro-network option is the most straight-forward and most likely to be implemented rather quickly. However, it doesn't solve the fundamental capacity crunch in the radio access network. Therefore its value is limited to being an optimization of the packet core/transport network. Some other tangible benefits would be reduction in latency to increase effective throughput for customers as well as easier capacity planning since transport facilities don't need to be dimensioned for large number of radio access network elements anymore.
LIPA provides a limited benefit of allowing access to local premises networks without having to traverse through the mobile operator core. Considering it is dependent on the implementation of femtocell, this benefit looks rather small and has no impact on the macro radio network capacity. If LIPA is extended to access to Internet and Intranet, then the additional offload benefit would be on the mobile operator core network similar to the SIPTO macro-network proposal. Femtocell solves the macro radio network capacity crunch. However, the pace of femtocell deployments so far doesn't show a significant momentum. LIPA's market success will be limited until cost of femtocell ownership issues are resolved and mobile operators decide why (coverage or capacity) to deploy femtocells.
IFOM is based upon a newer generation of Mobile IP that has been around as a mobile VPN technology for more than 10 years. Unfortunately success record of mobile IP so far has been limited to enterprise applications. It hasn't become a true consumer-grade technology. Introduction of LTE may change this since many operators spearheading LTE deployments are planning to use IPv6 in handsets and adopt a dual-stack approach of having both IPv4 and IPv6 capability. Since many WiFi access networks will stay as IPv4, DSMIPv6 will be the best tunneling mechanism to hide IPv6 from the access network. Having dual-stack capability will allow native access to both legacy IPv4 content and native IPv6 content from major companies such as Google, Facebook, Yahoo, etc. without the hindrance of Network Address Translation (NAT). Considering the popularity of smartphones such as iPhone, Blackberry and various Android phones, they will be the proving ground for the feasibility of DSMIPv6.
Source of the above content: Whitepaper - Analysis of Traffic Offload : WiFi to Rescue
Wednesday, 24 November 2010
IP Flow Mobility and Seamless Offload (IFOM)
Unlike LIPA or SIPTO that are dependent on upstream network nodes to provide the optimization of routing different types of traffic, IFOM relies on the handset to achieve this functionality. It explicitly calls for the use of simultaneous connections to both macro network, e.g., LTE, UMTS and WiFi. Therefore, IFOM, unlike LIPA and SIPTO, is truly a release 10-onward only technology and it is not applicable for user terminals pre-Release 10. IFOM is being specified via 3GPP TS 23.261 [1]. Following diagram shows the interconnectivity model for IFOM capable UE.
IFOM uses an Internet Engineering Task Force (IETF) Request For Comments (RFC), Dual Stack Mobile IPv6 (DSMIPv6) (RFC-5555) [2].
Since IFOM is based on DSMIPv6, it is independent of the macro network flavor. It can be used for a green-field LTE deployment as well as a legacy GPRS packet core.
Earlier on we looked at the mobile network industry attempts of integration between packet core and WLAN networks. Common characteristic of those efforts was the limitation of the UE, its ability to use one radio interface at a time. Therefore, in earlier interworking scenarios UE was forced to use/select one radio network and make a selection to move to an alternative radio for all its traffic. Today many smartphones, data cards with connection managers already have this capability, i.e., when the UE detects the presence of an alternative access network such as a home WiFi AP, it terminates the radio bearers on the macro network and initiates a WiFi connection. Since WiFi access network and packet core integration is not commonly implemented, user typically loses her active data session and re-establishes another one.
Similarly access to some operator provided services may not be achieved over WiFi. Considering this limitation both iPhone IOS and Android enabled smartphones to have simultaneous radio access but limited this functionality to sending MMS over the macro network while being connected to WiFi only.
IFOM provides simultaneous attachment to two alternate access networks. This allows fine granularity of IP Flow mobility between access networks. Using IFOM, it will be possible to select particular flows per UE and bind them to one of two different tunnels between the UE and the DSMIPv6 Home Agent (HA) that can be implemented within a P-GW or GGSN. DSMIPv6 requires a dual-stack (IPv4 or IPv6) capable UE. It is independent of the access network that can be IPv4 or IPv6.
[1] 3GPP TS 23.261: IP flow mobility and seamless Wireless Local Area Network (WLAN) offload; Stage 2
[2] RFC-5555: Mobile IPv6 Support for Dual Stack Hosts and Routers
[3] 3GPP TS 23.327: Mobility between 3GPP-Wireless Local Area Network (WLAN) interworking and 3GPP systems
Content Source: Analysis of Traffic Offload : WiFi to Rescue
Tuesday, 23 November 2010
Presentation: Smart Antennas and SON
Smart Antennas and SON
Presented by Kevin Linehan, VP, CTO Antennas, Andrew Solutions in the 4G World, Oct. 2010
View more presentations from Zahid Ghadialy.
Monday, 22 November 2010
Carrier aggregation deployment scenarios for Release-10 LTE-A
One of the important aspects to consider is that carrier aggregation should allow aggregation of not only the existing bands, but also bands that are introduced in future, e.g., 3.5 GHz band, etc. While existing bands already have certain deployments, new deployments can be considered for new bands that are introduced. Since introduction of new bands is done in a release independent fashion, considerations for such future bands are essential already in Rel-10. When higher frequencies such as 3.5 GHz are considered, path loss can be significant (e.g., 4-10 dB difference in link budget) when compared to 2 GHz. Hence, the most efficient deployment may not be to stick with the traditional macro-overlaying approach. Carrier aggregation should allow more flexible use of such new bands, since coverage and mobility can be ascertained by the existing band deployments, e.g., 2 GHz.
Picture below shows some of the potential deployment scenarios for carrier aggregation. Note that the scenarios listed are non-exhaustive. For example, other scenarios using repeaters and femto cells may be considered. Also note that F2 > F1.
Scenario 1
* F1 and F2 cells are co-located and overlaid, providing nearly the same coverage
* Both layers provide sufficient coverage and mobility can be supported on both layers.
* Likely scenario when F1 and F2 are of the same band, e.g., 2 GHz, 800 MHz, etc.
* It is expected that aggregation is possible between overlaid F1 and F2 cells.
Scenario 2
* F1 and F2 cells are co-located and overlaid, but F2 has smaller coverage due to larger path loss
* Only F1 provides sufficient coverage and F2 is used to provide throughput. Mobility is performed based on F1 coverage.
* Likely scenario when F1 and F2 are of different bands, e.g., F1 = {800 MHz, 2 GHz} and F2 = {3.5 GHz}, etc.
* It is expected that aggregation is possible between overlaid F1 and F2 cells.
Scenario 3
* F1 and F2 cells are co-located but F2 antennas are directed to the cell boundaries of F1 so that cell edge throughput is increased
* F1 provides sufficient coverage but F2 potentially has holes, e.g., due to larger path loss. Mobility is based on F1 coverage.
* Likely scenario when F1 and F2 are of different bands, e.g., F1 = {800 MHz, 2 GHz} and F2 = {3.5 GHz}, etc.
* It is expected that F1 and F2 cells of the same eNB can be aggregated where coverage overlap.
Scenario 4
* F1 provides macro coverage and on F2 Remote Radio Heads (RRHs) are used to provide throughput at hot spots
* Mobility is performed based on F1 coverage.
* Likely scenario when F1 and F2 are of different bands, e.g., F1 = {800 MHz, 2 GHz} and F2 = {3.5 GHz}, etc.
* It is expected that F2 RRE cells can be aggregated with the underlying F1 macro cells.
Scenario 5
* Similar to scenario #2, but frequency selective repeaters are deployed so that coverage is extended for one of the carrier frequencies
Scenarios supported in Rel-10 time frame
* For DL, all scenarios are supported in Rel-10
* For UL, scenario 4 and 5 are not supported in Rel-10
Source: R2-100531 CA deployment scenario NTT DOCOMO
Saturday, 20 November 2010
Friday, 19 November 2010
CA (Carrier Aggregation) Scenarios in LTE-Advanced
CA (Carrier Aggregation) may be used in three different spectrum scenarios as follows.
Intraband Contiguous CA — This is where a contiguous bandwidth wider than 20 MHz is used for CA. Although this may be a less likely scenario given frequency allocations today, it can be common when new spectrum bands like 3.5 GHz are allocated in the future in various parts of the world. The spacing between center frequencies of contiguously aggregated CCs (Component Carriers) is a multiple of 300 kHz to be compatible with the 100 kHz frequency raster of Release 8/9 and preserving orthogonality of the subcarriers with 15 kHz spacing.
Intraband Non-Contiguous CA — This is where multiple CCs belonging to the same band are used in a non-contiguous manner. This scenario can be expected in countries where spectrum allocation is non-contiguous within a single band, when the middle carriers are loaded with other users, or when network sharing is considered.
Interband Non-Contiguous CA — This is where multiple CCs belonging to different bands (e.g., 2 GHz and 800 MHz are aggregated). With this type of aggregation, mobility robustness can potentially be improved by exploiting different radio propagation characteristics of different bands. This form of CA may also require additional complexity in the radio frequency (RF) front-end of UE. In LTE Release 10, for the UL the focus is on intraband CA, due to difficulties in defining RF requirements for simultaneous transmission on multiple CCs with large frequency separation, considering realistic device linearity. For the DL, however, both intra and interband cases are considered in Release 10, while specific RF requirements are being developed.
Text Source: Carrier Aggregation Framework in 3GPP LTE-Advanced - Mikio Iwamura et al. in IEEE Communications Magazine August 2010
Picture Source: http://www.catr.cn/tecm/dxwjs/201006/t20100610_1143968.htm
Thursday, 18 November 2010
Wednesday, 17 November 2010
The Path to 4G: LTE and LTE-Advanced
The Path to 4G: LTE and LTE-Advanced
View more presentations from Zahid Ghadialy.
The Path to 4G: LTE and LTE-Advanced presented by James Seymour, Alcatel Lucent in 4G World, 20th Oct. 2010.
Monday, 15 November 2010
HTML5 for Mobile Devices
I had been recently talking to some developers about the programming and App development on mobiles and quite a few people are of the opinion that HTML5 may help the mobile Apps go to the next level.
The biggest problem HTML5 is supposed to solve is write once run anywhere applicatons. Most of the programs will have the same look and feel if they are run on a PC or mobile and between different devices.
Ofcourse not everything is perfect. There are yet many API's that need to be implemented in for HTML5 like the 3D and Mic API's, etc. Another problem is that a lot of phones are not yet supporting HTML5 and some of them that are supporting, not supporting it completely. This will have to be solved asap.
The following is a recent presentation from Ericsson on HTML5 that gives a good idea on why it is a good idea.
HTML5 impact on application programming
Another interesting place to look for some HTML5 stuff is Patrick Chanezon's html5 BookmarksView more presentations from Ericsson Labs.
Thursday, 11 November 2010
UEInformationRequest/UEInformationResponse - New RRC messages in Release-9
As is obvious from the title, The UE information procedure is used by E-UTRAN to request the UE to report information [1].
There are two different scenarios for the Network to send the UEInformationRequest message to the UE. One is to find out the number of RACH preambles it needed for the random access procedure and the other is to get the measurement information when a Radio Link Failure (RLF) occurred.
[2] also provides the following detail:
The network may poll for the UE report after a successful random access procedure (UEInformationRequest) and the UE responds with the number of preambles sent by MAC for the last successfully completed random access procedure and whether contention is detected by MAC for at least one of the transmitted preambles for the last successfully completed random access procedure (UEInformationResponse).
Source:
[1] 3GPP TS 36.331 V9.3.0: Radio Resource Control (RRC); Protocol specification - Section 5.6.5
[2] 3GPP TR 36.902 V9.2.0: Self-configuring and self-optimizing network (SON) use cases and solutions
Wednesday, 10 November 2010
Proximity Indication - New RRC Uplink Message in Rel-9
The inbound handover from a Macro eNB to an HeNB (a.k.a. Femtocell) is not supported in Release 8. Before making a handover decision to a HeNB, the Macro eNB needs to acquire UE measurement information related to the so-called target CSG cell. Nevertheless, UEs cannot continuously make measurements and read the system information of lots of CSG cells in cases of large scale HeNB deployments.
In order to allow the UE to make those measurements efficiently, a newly defined proximity report can be configured within the RRC Reconfiguration message. This proximity report will allow the UE to send a so-called “proximity indication” to the source eNB in the uplink whenever it is entering or leaving the proximity of one or more cells with CSG IDs that the UEs has in its CSG Whitelist.
A UE that is able to determine that it is near its CSG cell can thus inform the network to take the necessary actions for handover preparation. The detection of proximity is based on an autonomous search function.
The source eNB, upon receiving the proximity indication, might ask the UE to perform measurements of the CSG cell, to read the System Information (SI) or, in case it already has all required information, it might already start the handover procedure. PCI (Physical Cell Identification) confusion is resolved in Release 9. The eNB will ask the UE to report the global cell identity. As usual the UE reporting is using the RRC measurement procedures. The ovell procedure is illustrated in Figure below.
In summary five basic steps can be identified:
1. Proximity configuration/reporting
2. HO measurement configuration/reporting
3. Resolution of PCI confusion by requesting and reporting System Information
4. Access Control in the network
5. HO execution
Since the CSG search can be very slow there are no strict requirements on the inbound handover performance, which can range from one to several 10’s of seconds.
Since the proximity information is based on UE signaling, the network might be receiving a lot of proximity indications, increasing the network load. Therefore, it was agreed to limit proximity indications a UE can send within a certain time frame. A timer, called the prohibit proximity timer, was introduced.
Source:
- 3GPP TS 36.331 v9.3.0 section 5.3.14
- Nomor Research Whitepaper - LTE Home Node Bs and its enhancements in Release 9
Tuesday, 9 November 2010
Monday, 8 November 2010
Single Radio Voice Call Continuity (SR‐VCC)
From a 3GPP presentation by Hannu Hietalahti
1. SR-VCC use case
1a. IMS call initiated in LTE can continue in CS domain after moving outside of LTE coverage area
1b. SR-VCC is invoked if no other VoIP capable PS system (e.g., HSPA/eHRPD) is available for VoIP PS-PS HO (Handovers)
1c. Only HO of a single voice bearer from PS to CS is specified
1d. Requires overlapping with 1xRTT/GSM/WCDMA coverage
2. SR-VCC allows a voice calls are anchored in IMS
2a. One-way HO from PS to CS systems (LTE to GSM/UMTS or LTE to 1xRTT)
2b. No simultaneous operation of different radio transceivers needed
3. Rel-9 SR-VCC improvements
3a. IMS support of mid call services (e.g., HOLD, MPTY)
3b. SR-VCC support for emergency calls
4. Video calls, reverse direction from CS call to IMS and optimisations are being studied in Rel-10
Saturday, 6 November 2010
LTE CS Fallback Procedure
From a 3GPP presentation by Hannu Hietalahti:
1. CS FallBack from EPS to CS domain
2. CSFB reuses voice and other CS-domain services provided by legacy CS infrastructure
3. EPS redirects the UE to CS Domain for CS services
3a. SMS can be delivered to the UE without redirecting to CS Domain
3b. After CS service the UE returns to LTE, depending on coverage and policy
4. User can decide, based on CLI, whether to accept CSFB request
5. Application of CSFB:
5a. CS capable device camping on LTE cell can establish/receive CS services
5b. Reuse of existing CS infrastructure for voice service until IMS VoIP is deployed
5c. Provide voice roaming support with LTE
5d. Support E911 using existing CS infrastructure
5e. Rel-9 IMS provides full emergency call support
5f. Requires overlapping CS domain coverage
Note: CSFB applies between LTE and GSM, WCDMA and 1xRTT
Friday, 5 November 2010
LTE CS and PS voice service capabilities and architecture
From a 3GPP presentation by Hannu Hietalahti:
Thursday, 4 November 2010
Emergency Calls in LTE/SAE Release-9
From a 3GPP presentation by Hannu Hietalahti:
Emergency calls in LTE
Regulatory requirement of emergency calls is supported in Rel-9 for LTE:
1. Detection of emergency numbers in UE
2. Indication and prioritisation of emergency calls
3. Location services, both for routing and user location data for PSAP (Public Safety Answering Point)
4. Callback is possible, but processed as normal call without exceptions
UE matches digits dialledby the user with list of known emergency numbers
1. Emergency number list in the UE is common for CS and PS domain use
2. Default 112 and 911, USIM pre-configuration, downloaded in MM procedure
3. In case of match, the UE shall initiate the call as an emergency call
In IMS emergency calls the UE translates dialled number into emergency service URN
1. Service URN with a top-level service type of "sos" as specified in RFC5031
2. Additionally, sub-service type can be added to indicate emergency category if information on the type of emergency service is known (fire, ambulance, police,…)
P-CSCF (Proxy - Call Session Control Function) must also be prepared to detect emergency call if the UE is not aware of local emergency call
1. This is backup for those cases when the (roaming) UE does not have full information of all local emergency call numbers and initiates a normal call
2. From EPC perspective, it will be a normal PDN connection
Benefit of location information
1. P-CSCF discovers the regionally correct PSAP to take the emergency call
2. PSAP gets information on the precise user location
Related Posts:
Wednesday, 3 November 2010
'Wi-Fi Direct': New Standard and competition to Femtocells and Bluetooth
Last month when I blogged about WiFi as 4G, i got mixed reactions. Some suggesting that WiFi is just a filler till Femtocells become prevalent and others suggested that in future all devices would with 3G/HSPA/LTE/4G enabled so there may be no need for WiFi.
Well, yesterday I read about the new Wi-Fi Direct (formerly known as 'Wi-Fi Peer-to-Peer') standard that is supposed to make WiFi devices easier to operate with other WiFi devices. I havent explored the security options but I am sure they are well thought out.
Before we go further, you may want to check out the WiFi Direct official video below:
There is an interesting piece in PC World that compares Bluetooth 4.0 with Wi-Fi Direct. I am sure soon both these camps would be listing the merit of their standards and dissing the other one. According to the Register, Bluetooth never really took off in the US. They think Wi-Fi has bigger clout and this would translate to WiFi Direct success.
WiFi Alliance has a recently revised FAQ on Wi-Fi Direct here. Very interesting read. A Media presentation is embedded below and can be downloaded from Slideshare here.
'Wi-Fi Direct' Media Presentation
The devices have already started undergoing certification and commercial devices should be available by the end of this year. View more presentations from Zahid Ghadialy.
Finally, while there is a lot of debate going on about WiFi v/s Femtocells and I respect everyone's views and arguments on this debate, I think Wi-Fi direct may give a kicking to the Femtocell manufacturers where it hurts the most.
One of the strong arguments in the favour of Femtocell is the seamless roaming. With Wi-Fi direct you may be able to seamlessly connect to various Wi-Fi devices and Access points. This certainly counts big time in their favour.
Certainly the gate is still wide open for some Femtocell based killer apps which would turn the tide in their favour but for now I am looking forward to some Wi-Fi direct devices.
Tuesday, 2 November 2010
Understanding smartphone traffic - Interesting Presentation
Monday, 1 November 2010
ETSI M2M Workshop summary and conclusions
As I mentioned earlier about the M2M workshop held in Paris, the following are the highlights from press release after the event:ETSI's first Open Machine-to-Machine Workshop broke all records for attendance, laying out the next steps for achieving M2M applications worldwide, and confirming a leading role for the standards organisation.
'Machine-to-Machine (M2M) communications need standards – and ETSI is taking the lead to make sure that the standards are in place.' This was the main conclusion from ETSI's M2M workshop which took place on 19 and 20 October. With over 220 attendees from across the world, this was the most popular ETSI workshop to date, with the high degree of interest reflecting the enormous potential that is foreseen for M2M applications and technologies.
Participants heard how existing and evolving communication technologies networks (mostly wireless (cellular and low-power), but also fixed networks, including power line communications) provide a firm basis for connecting M2M sensors and applications. Specification of appropriate interfaces that allow network technology neutrality is a priority, and one that ETSI is already addressing.
The workshop included two live demonstrations organised by InterDigital Inc. These demonstrated an M2M gateway and core network, and an M2M Wireless Personal Area Network (sensors connecting via low-power wireless devices to a database, simulating e-Health, home automation and security application scenarios). The implementations were based on current specifications from ETSI's M2M Technical Committee and confirmed both the effectiveness of the implications and of the ETSI specifications. In addition, poster sessions presented the work of six research and development projects related to M2M and the Future Internet, part of the European Commission's 7th Framework Programme (FP7).
The standards work of ETSI's M2M Technical Committee is reaching an advanced stage, and many network operators are encouraging a first release of M2M standards by early 2011. The committee is currently finalising the architecture for the service platform that will enable the integration of multiple vertical M2M applications. The workshop confirmed that ETSI is well placed to address a vital aspect of standardisation in support of M2M – the specification of interfaces that will facilitate the interconnection and interoperability of the diverse applications and of the networks that will underlie them.
Marylin Arndt of France Telecom, Chairman of ETSI's M2M Technical Committee, said: 'The committee will continue in its role of creating standards that build on what we already have, to ensure that the emerging 'vertical' M2M applications can be supported effectively. At the same time, the committee (and ETSI in general) has a vital responsibility to co-ordinate and direct the wider work on M2M. We are here to lead the way.'
All presentations could be downloaded from here.
The conclusions from the meeting is summarised in the presentation embedded below:
ETSI M2M Workshop Oct. 2010 Conclusions
View more presentations from Zahid Ghadialy
Subscribe to:
Posts (Atom)
