Search This Blog

Sunday, February 12, 2012

HSDPA fast facts

Basics
HSDPA is based on shared channel transmission in the time and code domain by enabling channel dependent scheduling in the nodeB based on frequent and highly accurate channel status reports from the terminals. In this way, terminals that are reporting good channel conditions are favored in the following scheduling moments. This approach increases the overall system throughput. HSDPA also uses a 2 ms TTI which enables faster and more efficient adaption of the transmitted signal to the varying channel conditions of a time dispersive channel. Furthermore, by controlling the bit rate with regular updates of the code rate, transport block size and modulation scheme, the transmission power can be utilized close to the max at nearly all times which is an  improvement compared to earlier releases which employed power controlled schemes.. Finally, Hybrid Automatic Repeat Request (HARQ) is introduced which enables a fast retransmission scheme for the majority of all retransmissions on top of legacy, slow RLC retransmissions which now only serves as a safe and reliable backup scheme in the rare event that HARQ fails. A new sub-layer, mac-hs is introduced in the nodeB and is in charge of the scheduling, rate control and HARQ. By placing these features closer to the air interface, signalling between the nodeB and the RNC is minimized which reduces latency and improves the accuracy of the chosen transmission parameters.     

Key features

High Speed-Downlink Shared Channel (HS-DSCH)

  • HS-DSCH is the transport channel used to support shared channel transmission, fast scheduling and 2ms TTI.
  • HS-DSCH consists of a set of 16 channelization codes (each with spreading factor 16) which corresponds to 16 High Speed Physical Downlink Shared Channels (HS-PDSCH)
  • To allow for code resources used for other purposes (R99 DCH) only 15 codes are available for HS-DSCH
  • HS-DSCH resources can be shared in the code domain as well as in the time domain
  • All transmission power that remains after serving all other channels is assigned to the rate-controlled HS-DSCH which gives a more or less constant transmission power.
High Speed-Shared Control Channel (HS-SCCH)

The HS-SCCH is transmitted in parallel with the HS-DSCH and carries the following information:
  • HS-DSCH transport format: channelization code set, modulation scheme and transport block size.
  • HARQ information: HARQ process number, redundancy version and new data indicator.

The HS-SCCH information is split in two parts depending on how urgently the receiver needs the information:
  • Part 1: channelization code set and modulation scheme for the HS-DSCH.
  • Part 2: transport block size and HARQ parameters.     
For identification needs, part 1 and 2 use different methods:
  • part two contains a CRC which is also used for identification of the receiving UE
  • part one uses a terminal specific masking operation which enables identification of the receiving UE.

High Speed-Dedicated Physical Control Channel (HS-DPCCH) and Fractional-Dedicated Physical Channel (F-DPCH)
  • ACK-NACK’s for each TTI that the UE has been scheduled in is sent in the uplink on High Speed Dedicated Physical Control Channel (HS-DPCCH).
  • Measurements on the downlink channel quality made by the UE are sent in the form of a Channel Quality Indicator (CQI) on the HS-DPCCH.
  • HS-DPCCH has a fixed spreading factor of 256 and 2ms/3-slot structure. First slot is used for HARQ and remaining two for CQI’s.
  • The F-DPCH is a slot format DPCH for Transmission Power Control (TPC) bits only which allows up to ten different users to share a single channelization code

 Scheduling:
  • The scheduler in Mac-hs decides what part of the shared code and power resources should be assigned to a user in a certain TTI.
  • Efficient scheduling relies on information about the instantaneous channel conditions which is conveyed by the CQI’s as well as buffer status information at the nodeB and negotitated QoS.
  • The CQI value which is received by the node B is directly mapped to a transport block size, modulation scheme and number of channelization codes.
  • Efficient scheduling also relies on buffer status information at the UE.
  • Certain types of data such as RRC signaling is prioritized in the scheduling process.
  • Since downlink scheduling takes place in the nodeB, HSDPA does not support macro-diversity or soft handover.

 Rate control
  • The data rate is adjusted for every TTI by selecting the most appropriate modulation, transport block size and channel coding based on the instantaneous channel conditions.
  • Although HSDPA is rate controlled and not power controlled, power can still change due to variations in power requirements for other downlink channels.

 HARQ
  • HARQ functionality resides in both physical layer and MAC.
  • HARQ introduces faster retransmissions compared to RLC since there is no signaling between nodeB and RNC and more frequent status reports (every TTI).
  • For continuous transmission to a single UE, multiple HARQ-processes can operate in parallel.
  • The number of parallel HARQ processes should match the roundtrip time between the UE and the nodeB.
  • Due to the multiple HARQ processes, the order of the transmitted transport-blocks may become corrupted at the receiver and therefore a mechanism for putting them back in sequence is required before they are passed on to higher layers (RLC)
  • In case a NAK is misinterpreted as an ACK by the transmitting HARQ entity, RLC will detect the error and request the necessary retransmission.
  • For HSDPA, HARQ retransmissions are made in asynchronous and adaptive mode which means that they they can be sent at any time and with any transport format.
  • A one-bit new data indicator is used in the transport blocks to distinguish between retransmissions and new data.
  • ACK/NACK's are always sent at predefined intervals after receiving the transport block. In this way the UE always knows which HARQ process they belong to


Mobility
  • The UE measurements reports are initiated and managed by the RNC.
  • The RNC can order the UE to change it’s serving cell based on the measurements reports.
  • When change of HS-DSCH serving cell takes place between different node B's, the source node B will flush it's buffers and it's up to RLC retransmissions to recover the lost PDU's.
  • However, with perfect timing of when to stop forwarding PDU's to the source cell retransmission can be completely avoided.
  • If both source and target cell belong to the same nodeB and it supports HARQ preservation, the buffer content at the time of the serving cell change will be transfered from the source cell to the target cell.
  • Change in the serving HS-DSCH cell may be triggered by measurement event 1D

UE categories

The UE HSDPA categories describe the UE capabilities in terms of:
  • Maximum number of HS-DSCH codes received
  • Minimum inter-TTI interval
  • Maximum transport block size
  • Maximum number of schemes
  • Supported modulation

Constellation rearrangement
  • Due to the outline of the symbol constellation diagram for higher modulation degrees, certain symbols (and transmitted bits) have a shorter distance to some of the neighbors in the diagram which makes them more likely to be received in error.
  • For turbo codes, systematic bits are of greater importance than parity bits.
  • For these reasons, there is a gain in rearranging the symbol constellation between retransmissions with regards to both parity bits and bits that were previously received in error.


Channel Quality Indicator (CQI)
The CQI value can be seen as a measure of the downlink channel quality as perceived from the terminals side. It is transmitted in every reporting period to the nodeB which uses this information for scheduling of further downlink data transmissions. Due to the shorter TTI in HSDPA the channel conditions are more static or, have less time to change, during the length of one TTI which improves the accuracy of the reports.
·         Based on SIR-measurements on the Common Pilot Indicator Channel (CPICH)
·         CQI is sent on the HS-DPCCH together with the ACK/NACK’s
·         An increase of one step in the CQI value represents an increase of SIR of the CPICH by one db
·         Each 5 bit CQI value is directly mapped to a transport block size (TBS), number of channelization code and modulation degree. Depending on the capabilities of the receiver, these values may differ between receivers for each CQI value.
·         The nodeB uses these mapped values as an input to the scheduling algorithm. However, he scheduling algorithm for most implementations also considers other parameters such as buffer status and priority levels.
·         The CQI values range between 0(worst) and 30(highest).
·         For highest efficiency and utilization of the retransmission and error correcting coding schemes, the CQI value chosen should result in a block error rate (BLER) not exceeding 10%. A too low BLER would lead to an under-utilization of the system.

·         CQI values is not only based on measurements of the common pilot channel SIR and EcN0. Other factors include: multipath environment, terminal receiver type, ratio of interference of the own base station compared with others.

·         CQI values and their respective mappings to TBS, number of channelization codes and modulation degree for each HSDPA category can be found in 3GPP spec 25.214
·         CQI values and their respective mappings to TBS, number of channelization codes and modulation degree for each HSDPA category can be found in 3GPP spec 25.214

Saturday, February 11, 2012

SUPL fast facts


SUPL was developed by the Open Mobile Alliance1 (OMA), a mobile communications industry forum that was created to bring open standards, platform independence, and global interoperability to the LBS market. More than 360 companies are represented in OMA, including MNOs and NEVs, wireless vendors, mobile device manufacturers, content and service providers, and other suppliers. SUPL standards acknowledge Assisted GPS (AGPS) as the most accurate location technology available today. SUPL architecture is composed of two basic elements: a SUPL Enabled Terminal (SET) and a SUPL Location Platform (SLP). The SET is a mobile device, such as a phone or PDA, which has been configured to support SUPL transactions. The SLP is a server or network equipment stack that handles tasks associated with user authentication, location requests, location-based application downloads, charging, and roaming.

The core strength of SUPL is the utilization, wherever possible, of existing protocols, IP connections, and data-bearing channels. SUPL standards are complementary to and compatible with C-Plane standards. SUPL supports C-Plane protocols developed for the exchange of location data between a mobile device and a wireless network, including RRLP3 and TIA-80144. SUPL also supports MLP (Mobile Location Protocol) and ULP (UserPlane Location Protocol). MLP is used in the exchange of LBS data between elements such as an SLP and a GMLC, or between two SLPs; ULP is used in the exchange of LBS data between an SLP and an SET.

Implementation: SUPL vs. C-Plane

Two functional entities must be added to the C-Plane network in order to support location services: a Serving Mobile Location Center (SMLC), which controls the coordination and scheduling of the resources required to locate the mobile device; and a Gateway Mobile Location Center (GMLC), which controls the delivery of position data, user authorization, charging, and more. Although simple enough in concept, the actual integration of SMLCs and GMLCs into the Control Plane requires multi-vendor, multi-platform upgrades, as well as modifications to the interfaces between the various network elements. As with any complex endeavor, the larger the scope of the program and the more parties that are involved, the greater the number of points at which failures can occur. LBS through SUPL is much less cumbersome. The SLP takes on most of the tasks that would normally be assigned to the SMLC and GMLC, drastically reducing interaction with Control Plane elements. SUPL supports the same protocols for location data that were developed for the C-Plane, which means little or no modification of C-Plane interfaces is required.

AGPS for Location-Based Services

The“A” in AGPS is the assistance data provided to mobile AGPS devices through a wireless network. With this data, mobile devices equipped with AGPS can compute positions more quickly and in much more difficult environments. Traditional GPS receivers work best in open areas that offer an unobstructed line of sight to the GPS satellites orbiting overhead. In places where GPS signals are weak, obstructed, or scattered, as is the case inside an office building or in an urban canyon, traditional GPS receivers compute positions intermittently at best and frequently cannot compute positions at all.

Call Flows

In the network-initiated and SET-initiated call flows detailed below, the GMLC does nothing more than provide the initial position for the position calculation sequence that is conducted between the SLP and the SET. The SLP and the SET communicate through ULP, a binary protocol that supports eight basic messages. These messages are used to initiate a SUPL session, exchange positioning and authentication data, and end a SUPL session. Communication between the SLP, the Client application, and the GMLC is done through MLP. Only two MLP message types, SLIR (Standard Location Immediate Request) and SLIA (Standard Location Immediate Answer), are used in either transaction sequence. This is important because although MLP is very complex, utilization of MLP in SUPL architecture is not.



Network initiated request


 
Step 1. The Client application queries for the location of the targeted SET by sending an SLIR message (Standard Location Immediate Request) to the SLP. The message contains an ID for the targeted SET, positioning preferences, routing information, and a transaction code. The SLP authenticates the request and then determines whether the transaction will be based on AGPS or another positioning resource.

Step 2. The SLP sends a SUPL INIT message to the targeted SET through SMS or WAP push. The message contains an access code, an address for the SLP, parameters for the positioning method that will be used, and a unique, SLP-generated Session ID.


Step 3. The SET authenticates the access code and connects to an IP network through GPRS, EDGE, or other means.


Step 4. The SET establishes a secure connection with the SLP and sends a SUPL POS INIT message to it. The message contains the ID of the Cell tower being used by the SET (Cell ID), a profile of the SET’s capabilities, a request for assistance data, and a unique Session ID generated by the SET. The SUPL POS INIT also contains a“hash”, or cryptographic distillation, of the SUPL INIT message that the SLP uses to authenticate the SUPL POS INIT message.


Step 5. The SLP authenticates the hash and sends an SLIR message to the GMLC to get a coarse position for the SET. The message contains the SET ID, an access code for the SET, and the ID of the Cell tower being used by the SET.

Step 6. The GMLC authenticates the request, then queries its Cell ID database to find the latitude and longitude of the Cell ID referenced in the SLIR message. The latitude and longitude of the Cell ID will serve as the initial position for the position calculation.


Step 7. The GMLC sends an SLIA message to the SLP. The message contains the SET’s coarse position and an ID number that corresponds to the access code sent in Step 5.


Step 8. The SLP authenticates the ID number and sends a SUPL POS message to the SET to start the position calculation process based on the coarse position sent by the GMLC. The message contains a unique Session ID that combines the Session IDs generated by the SLP and the SET in steps 2 and 4. This combined Session ID will be used in all of remaining messages exchanged between the SET and the SLP. The SUPL POS message encapsulates a message from one of the approved positioning protocols (RRLP6, TIA-801, or RRC). The SET and the SLP may exchange several SUPL POS messages while performing the position calculation.


Step 9. The position calculated for the SET is sent back to the Client application in an SLIA message. The message contains the latitude and longitude of the SET as well as an ID number that corresponds to the transaction code sent in Step 1.


Step 10. After sending the position of the targeted SET to the Client application, the SLP sends SUPL END message to the SET. This is the end of the transaction as far as the SLP and SET are concerned, although the GMLC or the Client application may have additional tasks to complete.



SET initiated request



Step 1. The SET connects to an IP network through GPRS, EDGE, or other means.


Step 2. The SET establishes a secure connection with the SLP sends a SUPL START message. The message contains the ID of the Cell tower being used by the SET (Cell ID), a profile of the SET’s capabilities, parameters for the positioning method, and a unique, SET-generated Session ID.


Step 3. The SLP sends an SLIR message to the GMLC to get a coarse position for the SET. The message contains the SET ID, an access code for the SET, and the ID of the Cell tower being used by the SET.


Step 4. The GMLC authenticates the request, then queries its Cell ID database to provide a latitude and longitude for the Cell ID referenced in the SLIR message. The latitude and longitude of the Cell ID will serve as the initial position for the position calculation.


Step 5. The GMLC sends an SLIA message to the SLP. The SLIA message contains a latitude and longitude for the Cell tower being used by the SET and an ID number that corresponds to the access code sent in Step 3.


Step 6. The SLP sends a SUPL RESPONSE message to the SET, which identifies the positioning method that will be used, and contains a unique Session ID that is a combination of the Session ID generated by the SET and a Session ID generated by the SLP. This compound Session ID will be used in all of the remaining messages exchanged between the SET and the SLP. The SUPL RESPONSE message may also contain an address for the SLP and authentication data if the transaction requires authorization.


Step 7. The SET sends a SUPL POS INIT to the SLP. This message contains some of the same elements as the SUPL START message, but also contains a request for assistance data.


Step 8. The SLP sends a SUPL POS message to the SET to start the position calculation process based on the coarse position sent by the GMLC. The SUPL POS message encapsulates a message from one of the approved positioning protocols. Several SUPL POS messages may be exchanged between the SET and the SLP during the position calculation.


Step 9. The SLP sends a SUPL END message to the SET declaring that the transaction has ended. This is the end of the session for the SET and the SLP, but the GMLC may perform additional tasks outside session.



GLOSSARY

SET
SUPL Enabled Terminal. A device that can communicate with a SUPL network. Communication with the SUPL network is handled
LBS
Location-Based Services. An extension of LCS that includes a wide variety of real-time services and takes advantage of burgeoning wideband wireless communication services.
LCS
Location Services. A generic term for services and related applications that are based on the geographic location of a mobile device, and are channeled primarily through wireless communication networks.
LSP
Location Services Provider. A mobile network operator or SUPL provider that manages location services for LBS subscribers.
SLP
SUPL Location Platform at the center of Figure 3 is responsible for all aspects of SUPL communication between the SET and the rest of the SUPL-enabled network. The SLP also provides all AGPS data services from the embedded AGPS Server engine, including providing assistance data and performing position computations.
MLP
MLP is used in the exchange of LBS data between elements such as an SLP and a GMLC, or between two SLPs.
ULP
ULP is used in the exchange of LBS data between an SLP and an SET.
SMLC
Serving Mobile Location Center (SMLC), which controls the coordination and scheduling of the resources required to locate the mobile device
GMLC
Gateway Mobile Location Center (GMLC), which controls the delivery of position data, user authorization, charging, and more.


Saturday, February 4, 2012

What is coming next after LTE and IMT-Advanced


Here’s an interesting prediction of what is possible to expect of mobile networks  in year 2020. In short this presentation predicts:

·         256 cores CPU’s

·         Storage cost down to 1USD/TB and with 30% stored in the “cloud”

·         Overall latency pushed down to 1ms by using a shorter frame length

·         Spectral efficiency can be improved by 10x by managing inter cell interference

·         10x more available spectrum

·         10x more base stations where 80% will be micro cells or smaller

This leads to the rather staggering number of 1000x increase in capacity by 2020 !!! 

 (spectral efficiency*available spectrum*more base stations)=10*10*10=1000