Archive for December, 2007

With the coming of age of packet-switched technology in preference to circuit-switched connections, many network systems are already based on soft-switch architecture. The fundamental concept in this architecture is that switching happens mostly in software. The role of software was previously minimal because switching used to happen in hardware. Connection circuits used to be established at the start of a call and torn down at call termination. With soft-switch architecture, the role of software is much more. Software therefore needs to be much more robust. Creating robust software involves many things but before that designers need to understand the requirements of such a software.

Yesterday at the British Council Library in Bangalore I picked up a wonderful book: Robust Communications Software by Greg Utas, published by John Wiley & Sons. The bulk of the book deals with the questions of “how” but the first chapter outlines the requirements of a carrier-grade system. I summarize these requirements with thoughts of my own.

Figure 1 shows the five basic attributes of a carrier-grade system. Although all are important in their own way, they are not necessarily of the same level of importance. It may be the case that reliability is more important that scalability. It may be that having a highly scalable system may require some compromise in terms of capacity. Some of these issues will be explained later in this post.

Figure 1: Requirements of a Carrier-Grade SystemCarrier grade system

While I was working in the UK, one morning the office phone system was down for about a couple of hours. During that time, there was no way for customers to reach either the support staff or the sales staff. The loss to the business was somewhat mitigated because some customers had the mobile contacts of our staff. Internally, e-mails served well during that interim period. I don’t know if we had a softswitch architecture in place. Either way, availability means that public communication sytems should be operational 24/7 all days of the week. Imagine someone trying to place an emergency call only to find that the system is down.

Likewise, on another occasion, I was at a seminar and the presenter failed to give his demo to the audience. The reason was that there had been a planned power shutdown at his office, of which he had been unaware. Shut downs should be minimized and in some cases eliminated. Where shutdowns are necessary for upgrades and regular maintenance, alternative systems should be operational during the shutdown phase.

A rule of thumb is to achieve an availability of five-nines: the system is available 99.999% of the time. This equates to a stringent downtime of 6 seconds in a week or 5 minutes 15 seconds in a year. System availability is dependent on the availability of its components. A chain is only as strong as its weakest link. Thus, if a system needs five-nines availability, then the software should provide six-nines availability and the hardware should provide six-nines availability (0.999999 x 0.999999 = 0.999998).

This implies that the system does not breakdown, behave erratically or respond in unexpected ways. The system should perform its job as expected. It is functionally correct and of a certain guaranteed quality. Availability and reliability when taken together make for robustness of the system.

Some months ago I was writing a piece of software for decoding MAC-hs PDUs. These are PDUs received on the DL on HSDPA transport channel HS-DSCH. One of the requirements from this decoder was that it should be robust. This meant that given an illegal combination of input stream and channel configuration, the decoder does not crash the system. It meant that the decoder identifies the set of possible errors and takes corrective/preventive actions as appropriate. This meant that given any random input (used for testing robustness), the decoder does a best-effort decoding without crashing the thread.

In telephone systems, reliability means that calls are handled as expected – no wrong numbers, no premature call termination, no temporary loss of the link, no crosstalk, no loss of overall quality. A typical goal is achieve four-nines reliability: only one in 10,000 calls is mishandled. However, for financial transactions the requirement is a lot more stringent.

This is important from the outset but this is often overlooked. When an new cellular operator sources for equipment, his requirement may be only a dozen base stations to cover a city. His expected subscriber base may be no more than a million. What happens if his growth is phenomenal? What if within the first year of operation he has to expand his network, improve coverage and capacity, and satisfy more than 10 million subscribers? He would like to scale his current system rather than purchase a new and bigger one.

Scalability is often in reference to architecture. A system that has five units can scale to fifty easily because the architecture allows for it. On the other hand, a system designed specifically for five units cannot scale to fifty because its architecture is inadequate. Changing system architecture in a fundamental during system resizing is not scalability. Scalability implies resizing with minimal effort. The effort is minimal because the architecture takes care of the resizing. There is no extra design or development, only deployment and operation.

Scalability applies downwards as well. For example, a switch may have 100 parallel mobules operating at full capacity. At off-peak times, it should be possible to power down 80 modules and run only on the remaining 20. I refer to this as operational scalability. Overall, scalability is a highly attractive feature for any customer. The architecture may not necessarily be fixed. It could be configured appropriately to suit the purpose at a particular scale.

As an example, I recently came across a system with multiple threads and synchronous messaging from each thread. The system was not scalable for two reasons:

  1. Each user had a dedicated thread, all running on the same CPU. They were all doing the same task, only for different users. This is acceptable for a few users but with thousands of users, the overhead from context-switching will be high. A distributed architecture might also suit.
  2. Synchronous communication meant that the thread blocked while waiting for a reply from an external entity. Such idle times are not a problem for a lightly loaded system. When thousands of users are involved, asynchronous messaging must be preferred to make best use of idle times. What this means is that requests and responses are pipelined. Requests could be on one thread and responses processed in another thread.

One easy way to explain capacity is to look at the PC market. Intel 386 is far below in terms of performance when compared to Intel Pentium 4. However, if we consider the overall system capacity we will realize that the improvement is less than what the numbers suggest. As processors have got better, so too is the demand from applications. Today’s applications are probably running at about the same speed as yesterday’s applications. Only thing that’s really improved is the user experience. So, has the capacity of processors really improved?

In fact, capacity is closely linked to scalability. What if the system can scale if capacity drops due to increased overheads? What if the system can scale if lot more processors are required than what the competition can offer?

This relates to maintenance and upgrade of software. No system today is quite simple. Complex systems must contain intelligent partitions and well-defined interfaces. These are generally managed by large teams. While no single person will grasp the details of the entire system, he will be an expert in his own component or sub-system. Activities happen in parallel – bug fixes, new feature releases, modifying requirements or patches. Good documentation is needed. Good processes leading to better productivity will increase the lifespan of a software system.

Some elements of a good software architecture are:

  • well-defined interfaces
  • layering (vertical separation)
  • partitioning (horizontal separation)
  • high cohesion (within components)
  • loose coupling (between components)

In conclusion, making a carrier-grade system does not happen right at the start. It is a process that involves continuous improvement. A good design is essential. Such a design will eventually meet all the five requirements that we have discussed. There are necessary choices to be made along the way. For example, a layered architecture suits well for large systems managed by large teams. It has good productivity but some parts of the system could have been of a higher capacity had they been of a leaner design. Likewise, application frameworks seek to provide a uniform API for applications. This increases productivity but at the expense of capacity.

Read Full Post »

Multiplexing at any level is a way of life because there is great deal of sense in doing it. In protocol engineering, people have long realized that packet-switched networks offer much better network capacity utilization than circuit-switched networks. In CS connections, the link or trunk is reserved for the entire duration of the call. Periods of inactivity or less than maximum rate lead to wastage of resources. In PS networks, any unused bandwidth is quickly deallocated and reallocated to users who need them. More importantly, when a single user has activated multiple services, all services could intelligently share the same underlying bandwidth without requiring fully dedicated resources.

Multiplexing is nothing but bringing together different streams of data into a single stream. While there are different types of multiplexing, in this post we are primarily concerned with time multiplexing of data. Multiplexing requires intelligence in terms of scheduling. In other words, when multiple services are waiting to share a single resource, someone has to intelligently schedule them based on priority, buffer occupancy, power, interference and other such factors.

In this post, I will look at multiplexing done at MAC for R99 transport channels, Rel5 HSDPA and Rel6 HSUPA. Simplifying the whole architecture, it is sufficient to note that for R99, independent data streams are carried in logical channels. There may be some dependence between logical channels that arrive from the same application (such as NB-AMR) but this does not matter to MAC where multiplexing is done. MAC would have been configured appropriately to handle these dependent streams in parallel. These logical channels are multiplexed to transport channels. Once configured, a logical channel can be carried on only one transport channel unless RRC remaps it to a different transport channel. Multiple transport channels exist at the same time. These are again time-multiplexed on the CCTrCh. Thus for R99, MAC multiplexing happens on two levels.

MAC decides what to multiplex for a given TTI. However, it has to obey the constraint set by the TFCS. The TFCS details the set of multiplexing possibilities. This set is formed based on the underlying physical layer capability to transmit data and the average bit rate promised for a given service.

Figure 1: Logical Channel Multiplexing in R99 MAC
R99 Mac Multiplexing

An example of R99 MAC multiplexing is in Figure 1. For this example, the TTIs of TrCh1, TrCh2 and TrCh3 are 10 ms, 10 ms and 20 ms respectively. We can note the following:

  • On any transport channel, only one logical channel can be carried at any one time. Logical channel will be identified in the MAC header.
  • Each logical channel has a PDU size of its own.
  • It is possible that in a given TTI, multiple MAC PDUs can be carried on the same transport channel. This is the case at time (t+20) for TrCh1. Specifications do not require that these PDUs should carry the same logical channel since each transport block has its own C/T field in MAC header to identify the logical channel. However, current specification require that all PDUs within the TTI for a transport channel must be of the same size.
  • It is possible that in some TTIs, nothing is carried for a certain transport channel. This is sensible if all logical channels mapped to the channel have no data to send. This can also happen if there are higher priority logical channels that need the bandwidth. This is the case with TrCh2 at time (t+20).
  • We ought to note that TrCh3 is of TTI 20 ms. We assume for this example that time (t) is on a 20 ms boundary. MAC decides to transmit 2 blocks of data at this time. This is sent on frames starting at (t) and (t+10).
  • Figure 1 is a gross simplification to demonstrate multiplexing at MAC. Actual transmission from PHY happens after many stages of processing that include interleaving, radio frame equalization and radio frame segmentation. The size of MAC header is variable and not fixed as suggested in the figure.
  • Since TrCh2 carries only one logical channel, MAC header will generally not carry any identification for the logical channel. However, MAC header will be still present because it has many other components.

Figure 2: Logical Channel Multiplexing in HSDPA MAC

Let us now turn to HSDPA for which we refer to Figure 2. Let us note the following:

  • There is only one transport channel. Only one transport channel can be carried on the CCTrCh. Although TFCS is defined it is not really a combination as in R99 channels.
  • Control information for multiplexing is embedded within the MAC-hs header while for R99 this control information is in the definition of the TFCS. Because of this, MAC-hs header is highly variable in size.
  • A new concept of MAC-d flow has been introduced for HSDPA. This is mainly used to differentiate traffic on the Iur and Iub. This applies for HSUPA as well.
  • Multiple logical channels can be carried on the same MAC-d flow.
  • A MAC-d flow can be carried on multiple priority queues. In other words, some logical channels of the flow are on one queue while others are on another queue. This is case with Flow 1 and Flow 2 in this example.
  • A priority queue can be used to handle multiple MAC-d flows. This is the case with Q2 in this example.
  • A TTI carries only one transport block. However, the MAC-hs PDU can contain multiple MAC-hs SDUs. The header indicates such multiplexing.
  • MAC-hs PDU can carry MAC-hs SDUs of different sizes. This is unlike R99. Example of this is at time (t+2).
  • A MAC-hs PDU can carry SDUs from only one MAC-d flow and only one priority queue. Thus, although at time (t+2) two different logical channels are carried, they belong to the same MAC-d flow and the same priority queue [TS 25.308, 6.1.4].
  • In R99, C/T field of MAC header is present if logical channels are multiplexed on the same transport channel. In HSDPA, MAC-d uses the same field when multiplexing is done on the same MAC-d flow.
  • Padding is used to fit a transport block size completely.

Figure 3: Logical Channel Multiplexing in HSUPA MAC

E-DCH multiplexing is shown in Figure 3. The following statements can be made of HSUPA MAC multiplexing:

  • Two TTIs are supported: 2 ms and 10 ms. Figure 3 represents the former.
  • As in HSDPA, a TTI can carry only one TB. A CCTrCH can carry only one E-DCH.
  • Multiplexing happens at MAC-e, rather than MAC-es. MAC-es only adds the TSN field in its header. Actual multiplexing information is in MAC-e header.
  • In HSDPA, multiplexing happens at two levels: at MAC-d which may add C/T field to a MAC-d SDU and at MAC-hs. In HSUPA, there is only one level of multiplexing. All of it happens at MAC-e. MAC-es SDU is simply RLC PDU. MAC-d does not add any header. This is because the information in MAC-e header maps directly to a logical channel. This is not the case with MAC-hs header which maps only to the level of a MAC-d flow.
  • Like HSDPA, there is a reordering queue. This is important in the SRNC that does the reordering of MAC-es PDUs. However, in HSUPA, there is one reordering queue for every logical channel. This makes sense because demultiplexing is already done by MAC-e before forwarding data to MAC-es. Reordering queue is not that important at the UE and hence it is not explicitly shown in the figure.
  • Header information is not contiguous. In particular, MAC-e and MAC-es headers are separate.
  • There is an optional padding as in HSDPA to fit a defined TB size. In addition, Scheduling Information (SI) can be sent if there is enough space or if there is a real need to send it.
  • Multiple MAC-d PDUs of a logical channel can be sent in the same MAC-e PDU. However, they should be of the same size.
  • When multiple logical channels are multiplexed, the MAC-d PDU size can be different from one logical channel to another.
  • It is possible for a MAC-e PDU to carry data from different flows [TS 25.209, 7.1.1]. An example of this is at time (t+4).

An additional comment is that a logical channel can carry RLC PDUs of multiple sizes. To my knowledge, NB-AMR Class-A bits is the only one that needs this feature at the moment. Even in this case, it is unlikely that PDUs of different sizes of the same logical channel would need to be sent in the same TTI. This may be one reason why in HSUPA there is a minor constraint on multiplexing as already noted. Otherwise, the design allows great flexibility.

In conclusion, there are significant differences in the three methods of multiplexing discussed above. On the surface they may appear to be similar but when we delve into the details we can appreciate the differences. This also highlights the way specifications have evolved. While R99 provides a layer of multiplexing at CCTrCh, this is no longer used in HSPA. I see this as an improvement because HSPA multiplexing allows for greater flexibility, quicker response and easier implementation. For example, in HSPA we need not do rate matching for multiple transport channels. In R99, if the CCTrCh carries a 80 ms transport channel, the TFCS reduces to a subset until the next 80 ms boundary. This restricts MAC scheduling to a certain extent. To avoid this, a much larger TFCS needs to be signalled at RRC. Blind TFCI TF detection is not applicable to HSPA. Fixed/flexible positioning of transport channels is not applicable either. These extra complications are removed by using a single transport channel per TTI for HSPA.

Read Full Post »

MoDeMo Bangalore, 16-Dec-07

On a cold but bright Sunday morning when the world preferred to stay in bed a little longer than usual, a bunch of mobile enthusiasts gathered at the office of ThoughtWorks in Bangalore. People as far Shimla and Cochin came for this open meeting that was free, productive and executed with minimal fuss. Having it on a Sunday was a departure from the usual MoMo meets of Mondays. Apparently, MoMo Bangalore has been receiving lots of requests for demonstrations. The best way to clear the backlog was to organize all of them together in this one-day event. It was focused on demonstrations rather than presentations; on audience interaction rather than news feeds; on real working products rather than market presumptions per se. Appropriately, it was named MoDeMo.

As many as 25 demonstrations were pre-registered and my guess is that we must have had about 20. I was personally present at 17 of them while I occasionally took time to chat with some of the speakers and gathered valuable insights into their products. I also met some others who had nothing to demo but had many interesting things to discuss. The agenda was well planned and you may view it at Vinu’s blog. In this post, I shall cover the gist of each demonstration in addition to offering my own thoughts.

1. Mobile Adult Literacy, Aditya Mishra, TCS

  • It takes about 400 hours to train an adult to read. This is too long a period to be effective. People lose interest. TCS has cut this training time to 40 hours. The approach is to teach based on context rather than start with alphabets on their own.
  • Software loaded on a mobile is the”teacher”. Interface is simple. People learn by listening to words that are read out by the software. They begin to recognize words that appear on the screen and associate them with the sounds.
  • About 93,000 have been made literate by this means. The success rate is higher in South India than in North India.
  • All learning is self-initiated. There are no classrooms.
  • More information is at TCS website.

2. MyDuniya – Integrating the Mobile and the Web World, Keshav Ganapathy

  • MyDuniya attempts to bring web services to the mobile. In other words, users no longer need to carry their PC and search for WiFi hotspots to get on to the web.
  • Services are both push and pull.
  • People can register to the site by SMS. A password will be returned by SMS. Subsequently, one can login, send e-mails, save notes and retrieve notes. For example, a user to push directions to a meeting venue to all participants via SMS. Likewise, the same directions could be stored on the server and retrieved by participants when they require it.
  • Personally, I found it difficult to appreciate the services because the demo was not well structured.

3. OnMobile, Prasad Murthy

  • OnMobile offers a number of VAS to operators.
  • There is not much else I remember of this demo because I was outside the room for quite sometime.

4. iPhone and 3rd Party Applications, Siddharth

  • One of the coolest demos that had everyone engaged.
  • Siddharth demonstrated a number of third-party applications on a “hacked” iPhone. His passing comment was that many of these applications are far better than those supplied by Apple.
  • A couple of games were demonstrated on the iPhone. One of them was a Labyrinth game that uses motion sensor technology. Tilting the phone moves the game’s ball down a slope. The chip that does this motion sensing is from STMicroelectronics.
  • Hacking an iPhone is an art on its own and those who have done it are “amazing”.

5. Mobile Mandi Bhav, Parul Awasthy, TCS

  • This is an mCommerce solution for farmers that enables them to get the best price for their products.
  • Current prices at nearby mandis can be retrieved by farmers for their specific commodity. The data comes NCDEX. Mobile location technology is used to locate nearest mandis.
  • Voice prompts read out the prices in regional languages, a feature through which the product reaches out to even illiterate farmers.
  • Technology is currently on CDMA but not on GSM. The application exists for both J2ME and BREW. A special phone (kisan phone) from Qualcomm is being used for current deployments.
  • My viewpoint: a good thing for farmers but we need to examine the greater social impact. A lot of people make their livelihood as middlemen. Their margins will decrease. There will be some farmers who have this technology and others who don’t. Middlemen will exploit this to their advantage. Technology is one thing but acceptance and effective application is another.

6. MOSH, Prakash & Bala, Nokia

  • Mobilize and share. Create, upload and share content.
  • MOSH is in beta version. There are about a million users at the moment.
  • A GPRS connection is required. A MOSH client needs to be on the phone.
  • An example of sharing content was demonstrated. By sharing, an SMS is sent to the recipient who can then follow the link to get more details and download content if interested.
  • MOSH attempts to create a community for mobile users the way communities exist on the Web.
  • Forum Nokia works with developer community in developing applications. They provide business support as well. As an example, a promising application may be pre-installed on phones or downloaded and installed for free trials.

7. Enterprise Tracking with Mobile LBS, Deepak Srinivas, Mobiance

  • I know the guys at Mobiance very well. They are focused and believe in their value proposition.
  • The demo was well-structured and smoothly executed. The location of a mobile (carried by one of their staff) was tracked. This was displayed on a map. The results were accurate but the display was a little slow. The previous locations of the mobile had been recorded at regular intervals and this was shown at the demo.
  • More details on their LBS products/services are at their website and in November’s MoMo event.

8. OpenGL based Games, Selvan

  • Selvan started with the intention of developing games but did not find any suitable game engine. So his current focus is on developing the engine.
  • From the little I understood, the development is on Google’s Android platform. Application is developed using Java and cross-compiled to Google class file.
  • Android SDK comes with OpenGL ES 1.0 specification for graphics. Selvan’s current activity is to develop the gaming engine based on this specification.
  • The demo was a basic “snake” game on an emulator. Nothing impressive but it was a good proof of concept, a stepping stone for developing more powerful games.
  • One question that bothered some was – how do we write applications that are portable across platforms? With BREW, J2ME, Windows Mobile, Android, iPhone, Symbian … it’s an important question. Someone mentioned OpenC and Java OpenGL. Rajeswari from Nokia commented that OpenC facilitates easy porting of applications. For example, the work was minimal in adapting an application written for Symbian to work on Linux.

9. Online Video on Nokia Phones, Rajeswari, Nokia

  • I remember more of what she said than what was demonstrated. The reason probably is that the mobile screen was not properly projected on the wall. Even if the phone played video at good frame rate without jitter/delay, it was difficult to judge anything from the projection.
  • The idea is to be able to play YouTube (and the like) videos on the phone. H.263 video codec is supported and support for H.264 is coming up shortly.
  • iPhone supports any video based on RTSP. Flash is not supported.
  • Frankly, I was not able to appreciate this demo which is why I remember so little of it. There is nothing innovative or revolutionary here.

10. Opera Mini Browser, Navjot & Sagar

  • I enjoyed this demo. It was really a demo; no silly talk and nonsense. Part of the reason was that participants asked questions.
  • Next time you need to visit a website, there is no need to get to a cyber cafe. Install JVM on your phone, install OperaMini (which is free) and start browsing.
  • I was always wary of scrolling huge web pages on a small mobile screen. OperaMini scales the page to fit the screen. Clicking on an area or specific link, zooms the page to the right level. The best part I thought was that users don’t need to scroll across (side to side) since pages are re-formatted to the width of the screen. Mind you, this is not a condensed version. There is no loss of information; just reformatting to make it user-friendly.
  • Users need to open an account on the server. Bookmarks between your desktop and mobile are automatically synchronized. Reformatting is done by the proxy server. SSL from the mobile terminates at the proxy and this was of concern to some.
  • OperaMini is based on Java and J2ME. It is the most downloaded Java application. Opera Mobile is a lot more powerful but it is not free.
  • It was shown that downloads were shrunk in sizes for faster downloads and reduced costs. OperaMini caches data but generally only on phones that have sufficient capability to do so. Flash is not built-in. It is a plug-in.

11. Zook.in – Mobile Social Search, Sameer Shishodia, Ziva Software

  • Two problems to be solved: small form factor, immediate result. The first is easy to understand. Search results have to be terse and to the point. The second implies that results from online search engines are far from perfect. Users often have to filter information manually and/or initiate a modified query.
  • Results are answers, not links to where the answers reside.
  • The search model is interactive. Instead of merely presenting users reams of information, users are given some choices/questions. This is to lead users to refine their search queries. This leads to establishing the context of search to yield more relevant results.
  • Zook recognizes that not all information is digitized. Local communities know things that are often untapped. If answers don’t match, the community is invited to answer questions. This is a search engine with true interactivity.
  • With mobile search, there is always an element of localization (LBS). Search results are biased to current location.

12. SMS Gupshup – Mobile Social Messaging Platform, Tathagata, Webaroo

  • It is truly remarkable how much mileage people can get out of SMS, a really basic technology. Again, there is nothing revolutionary here but the idea has a business case. SMS Gupshup is blogging from the mobile using just SMS.
  • Current model is one publisher, multiple readers. Readers subscribe to a blog via SMS. Posts are delivered to them via SMS. Comments are posted on the website but not broadcasted to the subscribers.
  • The model is flexible. It can be used for delivering group SMS rather than mobile blogging.
  • About a million users as of today. About 2-2.5 lakhs of SMS are going out per day. The speaker quoted an example of a successful blog: Sinleng News.
  • CDMA phones can’t handle SMS segmentation/concatenation. Anything more than 140 characters is delivered as multiple SMS messages.
  • My viewpoint: we are living in a strange dichotomy. On one hand, people want to communicate, be recognized within virtual communities and express themselves freely. On the other hand, people have to be brief in what they say because an SMS is only 140 characters! So while we have advanced technologies offering high bandwidth, the best we can do for the mass market is SMS because nothing else has a business case at this point in time.

13. Mobile Map Application that does not require GPRS, Vishnu

  • While Mobiance delivers map data over GPRS, Vishnu’s approach avoids GPRS by having map data stored on the phone. Of course, the downside is that it works only so long as you are within the area covered by the map. But this may be sufficient for most users who roam only occasionally.
  • For example, a user in Bangalore may preload Bangalore map data on his phone. This may be all he needs if he rarely leaves Bangalore. The great advantage is that GPRS charges are not incurred which at the moment is prohibitive.
  • Map rendering is done on the phone. It’s a J2ME application. While Google maps are raster data, this one uses vector data which is superior.
  • The engine is about 270 kB. The map for Bangalore is about 700 kB. This has been highly compressed from its original size of a few MB.

14. Mobile Visa Money Transfer, Naveen Thangiah, mChek

  • mChek eliminates the plastic in favour of a virtual debit/credit card stored on the phone. This can be used for online or across the counter just as a normal card.
  • There are security procedures as would be expected. This includes a user generated PIN. mChek performs necessary procedures with the banks and delivers the virtual card to the user’s phone.
  • Naveen himself uses it for paying bills and booking airline tickets. mChek has partnered with three banks as of today.
  • GPRS is not used. SMS and USSD sessions are used. The application itself is based on Java.
  • The demo included transfer of some money to one of the participants. Money transfer takes about 48 hours.

15. Mobitop – a Mobile Application Platform, Lalit, Mobisy

  • I was just about getting bored with applications that attempt to bring web services to the mobile when this demo woke me up for being different. Their idea is to use Javascript to access phone features.
  • For example, m.facebook does not allow access to phone contacts. This would be a desirable feature for users of m.facebook.
  • Mobitop does not use native APIs (Symbian for example). Instead it uses web technologies (Javascript and CSS). Thus the product brings value by adding something more than what’s possible with only applications written for the platform.
  • The demo showed loading of the Mobitop platform on a phone and display phone contacts in a customized manner. We should note that the platform needs to be loaded only once. Applications can be written using APIs exposed by the platform. It is claimed that writing applications is extremely easy.

16. Mango Application Framework, Sunil Maheswari, Mango Technologies

  • Sunil strongly believes that in Indian market, growth would come from low-end segments for whom GPRS is cost prohibitive. He quoted that GPRS connection is used by less than 5% of Indian subscribers.
  • The idea of this framework (about 150 kB) is to deliver applications to enhance user experience on a low-end handset. It would not be possible to match the look and feel of smart phones but the bold attempt is to get as close as possible.
  • The demo showed a simple game with reasonably good graphics.
  • The company has won Nasscom’s innovation award in startup category. Customers are OEMs, ODMs, operators and chipset vendors.

17. SMS Social Networking in Babalife , Sean Blagsvedt Company, Babalife

  • Okay, this is yet another social networking service trying to do from the mobile what used to be from the PC.
  • All interaction is done via SMS. While MOSH is graphic intensive and uses GPRS, Babalife is textual and purely SMS. Each is targetting a different segment of the market. Which one has a greater profit margin and growth potential? For the moment, it appears that they may complement rather than compete.
  • SMS Gupshup is blogging using SMS. The user is free to write in anyway he wishes. There is no format. From the brief demo that was presented, I think Babalife is a lot more intelligent. It presents users options along with organization of data. Although every SMS is an independent message, it maintains a logical view of a session in which interactivity can be achieved. I may be wrong in my interpretation but such an interactivity can add value to the service. There is only so much we can get from SMS.
  • If there is to be value in using SMS, there ought to be intelligence behind the scenes. If SMS is used for its traditional intent, it is a service for the user. With all the different applications showcased in today’s demos it is clear that for data applications using SMS, SMS is nothing more than bit pipe. It will remain so for some time to come but only if GPRS remains expensive in relation to SMS. At the end of the day, if all these services increase SMS traffic on a mass scale, operators may be forced to change their plans and increase SMS pricing. After all, it is a market of supply and demand. This price may be passed on to end consumers for SMS delivery or to service/content providers/partners who use their SMS gateways.

18. instablogs, Ankit Maheshwari, Citizen Media Pvt. Ltd

  • I had an informal chat with Ankit. He was full of enthusiasm about his product that it was impossible to resist the temptation to know more.
  • The idea of instablogs is to present news in brief to readers, just the gist leaving out detailed opinions and analysis. It is then left to readers to supply their own perspectives. The voice of the common man is given prominence.
  • While there are many sites that solicit comments from readers, here readers take centrestage. While comments at sites are often difficult to navigate or filter, instablogs makes a clear separation between those who agree and those who don’t.
  • When a news happens, the local perspective of the news is just as important as the global perspective. So while people in Delhi may have an opinion on President’s rule in Karnataka, the view of Bangaloreans is just as important. instablogs provides the framework for all views to be heard on an equal footing.
  • News items are gathered from established and reliable sources. Items are displayed not as links but directly on instablogs for easy navigation and contribution of comments.
  • Comments are filtered so that obscenity and abuse is eliminated. Overall, instablogs aims at the intelligent public.

During the day I met others from Proteans, Stoke, Mobme Wireless, Fone Arena, Evolvus and Microsoft Research. The day ended with a riveting discussion of what could be in store for the Indian mobile industry in the coming year. Mobile advertising was certainly touched upon, on which I will be posting something soon. I left this discussion early to attend a call. Overall, it was a Sunday well-spent – a good lunch, a free T-shirt and lots of knowledge gathered from experts. My summary of the demos is in Table 1. This is of course an opinion based on what I have understood. You may differ. Feel free to add your comments.

Table 1: Spectrum of Innovative Activities in Indian Mobile Industry
MoDeMo Table

Read Full Post »

Power Control in HSPA

Last week I wrote about UMTS power control with reference to R99 channels. Today’s post continues the discussion with reference to HSDPA and HSUPA.

Let us begin with HSDPA for which power control is significantly different from R99 channels. HSDPA does not have fast power control as in R99 DL DPCH. However, power control is just as important for HSDPA. Inner loop power control happens implicitly in HSDPA based on Adaptive Modulation and Coding (AMC). This can be understood by acknowledging that WCDMA is an interference limited system. Although reducing power, results in reduced interference this does not have significant impact for users close to the Node-B. Such users do not benefit much by decreasing power nor does system capacity increase. It is known that power control dynamics is only 20 dB in DL and 70 dB in UL [1]. Beyond the 20 dB limit, new techniques such as AMC are more beneficial.

Thus, when users close to the Node-B experience excellent channel conditions, modulation could be changed from QPSK to 16 QAM with an additional increase in coding rate (less redundancy). This increases bandwidth for a given user. Within the cell/sector, fast scheduling (another new feature in HSDPA) enables quick decisions so that one user may be given/denied more resources for relatively short time periods to make the best use of channel conditions at that moment in time. This increases overall system capacity towards what is optimal. Such benefits were not possible with only R99 fast power control.

We can infer that power control is done implicitly because when modulation and coding are changed based on CQI feedback received from the UE on UL HS-DPCCH, Node-B will also adjust its transmission power. Every CQI is associated with a reference power offset that is used by the UE when it calculates the CQI to send to the Node-B [TS 25.214, 6A]. This calculation is also dependent on the UE category.

Of course, open loop power control exists. The Node-B is commanded by the CRNC with specific power offsets. There is a power offset for HS-SCCH that’s relative to DL DPCCH power. For HS-PDSCH, where multiple codes are used, all codes will be transmitted with the same power [TS 25.214, 5.2.11]. The transmission that the Node-B can use for HS-PDSCH is indicated as a percentage of the total power available to the Node-B. This is indicated for every priority class with weights for every UE. Thus, differentiation in terms of priority and UE is partly implemented with these power weights [TS 25.433,]. It is then left to the Node-B to manage these power profiles efficiently. This is an implementation issue and has been the subject of many patents.

HSDPA has an associated channel in the UL (HS-DPCCH) that carries channel quality feedback and acknowledgments. CQI, ACK and NACK – all have their power offsets which are relative to UL DPCCH [TS 25.213,]. These offsets are signalled using NBAP to the Node-B.

Coming to HSUPA, the scenario is a little closer to the power control R99 UL channels. In DL DPCCH, there are always non-zero bits of TPC (Transmit Power Control) which are used for inner loop power control of the UL DPCCH and UL DPDCH. Power control of UL DPDCH is closely tied to UL DPCCH. There is defined offset between these two channels in terms of gain factors. These are either signalled at RRC or computed at Layer 1. Every TFC (Transport Format Combination) has a defined pair of gain factors. When computed, rate matching attribute, number of transport channel bits after radio frame segmentation and number of DPDCH are taken in account [TS 25.214,].

In HSUPA, the channels in question are E-DPCCH and E-DPDCH. Power control of HSUPA UL channels are tied to DPCCH. In fact, there is a requirement that E-DPCCH can be transmitted only if DPCCH is also transmitted in the same slot [TS 25.211,].

Complexity of HSUPA power control comes from the fact that inner loop and open loop controls are intimately tied to each other. For example, E-DPCCH power is signalled by RRC and it is relative to DPCCH power offset [TS 25.213,]. This offset does not change often because it is fixed by RRC at SRNC. However, inner loop controls the power of DPCCH which in turn affects the power of E-DPCCH.

RRC also signals the power offsets for each E-DPDCH. These offsets or gain factors are associated with E-TFC. This design gives flexibility to use higher power when data rate is higher. Actual gain factors for each E-TFC is calculated by the UE. Calculations take into account the HARQ power profile which is signalled at RRC [TS 25.213,]. This is similar to the weights given for priority classes for HSDPA. The computed gain factors are quantized to reference gain factors signalled at RRC.

The idea of using these reference gain factors is that every MAC-d flow is associated with a certain Q0S. The HARQ power profile allows this QoS to be met. If a MAC-e PDU carries only one MAC-d flow the power profile can be easily met. More commonly, data from different flows may need to be multiplexed in the same PDU to make the best of available bandwidth. For this reason, RRC signals a sets of compatible MAC-d flows that could be multiplexed in the same MAC-e PDU.

Of course, the UE ought to choose an E-TFC according to the amount of data it has to send. This is the case with R99 when UE chooses a TFC. The additional control for E-TFC is that amount of power the UE is allowed to use. This affects the UE MAC in its choice of E-TFC for the next transmission. These grants which are basically expressed in relation to power are sent on E-AGCH and/or E-RGCH channels. Thus, these two DL channels introduced for HSUPA play an important part in HSUPA power control by not just changing the power but also affecting the amount of data the UE is allowed to send. This can be seen as an enhancement or constraint to R99 inner loop power control.

An additional comment is that whatever happens, total transmission power from either the Node-B or the UE is fixed to a certain level. This level should never be exceeded. So if UL DPCCH is transmitted at a certain power, offsets and grants can be applied bearing in mind the upper limit. At the Node-B, there is an optional parameter that specifies the maximum power of HS-PDSCH, HS-SCCH, E-AGCH, E-RGCH and E-HICH taken together.

We now know that HSUPA inner loop power control is partly done using TPC bits of DL DPCCH. What happens if only HSDPA is required in the DL and DL DPDCH is redundant? This problem has been solved with the introduction of a new DL channel called Fractional DPCH (F-DPCH). This is a light-weight channel that functions just like DL DPCCH. The reason for introducing a new channel is to have minimum impact on previous releases of the standard. It was difficult to modify the slot formats of DL DPCH in a backward compatible manner since DL DPCCH and DL DPDCH are time multiplexed.


  1. Harri Holma and Antti Toskala, WCDMA for UMTS, Second Edition, John Wiley & Sons, 2002.

Read Full Post »

Older Posts »