A Hybrid Network Incorporating Community Radio

Randy Wang



1. Example use cases


Let us begin by examining some hypothetical use cases involving the system illustrated in the figure below.  In the discussions of the following paragraphs, I'm going to use example hypothetical scenarios of the system being used for school children education ("Digital StudyHall," or "DSH") and rural healthcare information dissemination ("Digital Polyclinic," or "DPC"), two areas in which we have had some experience.  I speculate that these scenarios are highly likely to be applicable to agriculture extension and other areas of work as well.
This figure illustrates a hybrid network integrating community radios, voice over land-line and cell phones, SMS messaging, and data communication.  An example application is a voice chat system that allows students and teachers from multiple "DSH villages" to "chat" across a long distance: participants can send "input" by simply placing cell phone calls to a "hub server," and receive "output" as they hear the entire community chatting on their regular FM radio receivers, which receive their signal from a local village FM transmitter, which is in turn driven by a local village "base station," which in turn communicates with the "hub" via a variety of means.  The "hub" may be run by and embedded inside grassroots leadership organizations such as the schools, hospitals, and NGOs that we work with in DSH and DPC and have a track record of excellence in outreach work.  In this illustration, we have shown only one hub, highlighted in yellow; but one may imagine many more similar inter-connected hubs in a larger "hubs-and-spokes" system.

Kids and trainee teachers from various villages, teachers and staff from the hubs, and even volunteers from the US may participate in such a "chat room," conducting a wide variety of educational activities, such as science questions and answers, story and book reading, math quiz and game shows, complementing in-class curricula in these after-school activities.  These chat sessions can also be digitally stored in a database, spliced, and re-used in the future. 

In this scenario, the "fringe" is populated by simple, cheap, and practical devices like conventional FM radio receivers and cell phones, while the "core," run by the various "hub" organizations, contains the intelligence, storage, and communication means to drive these fringe devices, uniting them into a coherent whole, providing functionality above and beyond what these fringe devices are capable of in isolation today.  Indeed, we may think of the FM radios and cell phones in the system as extreme versions of "thin clients" and the inter-connected hubs as "the cloud."

Let us consider a second possible use case.  In the past half year or so, we have been working with a partner hospital on a DSH-spin-off that does rural healthcare information dissemination, and in the process, we have learned some lessons.  Villagers in the rural areas that we work in rarely seek help or information unless they are desperate.  For example, symptoms such as chronic cough, bleeding during pregnancy, an infant having stopped crying rarely prompt action.  This is due to a variety of difficulties such as lack of transportation, concern of potential costs, lack of time, and cultural discomfort of letting women travel alone etc.  Indeed, many of these villagers could live their entire lives without ever having consulted a healthcare professional. 
When smaller health problems are not dealt with early, they could get worse and become too late and too expensive later.

The fact that these various obstacles prevent the villagers from seeking care, however, does not mean that they are not keenly interested in getting the relevant information to help themselves, only if it were more easily available--when staff visits these places for various reasons, they are always swamped with queries.  We would like to employ a system as the one illustrated above to allow villagers to more easily get help on the common healthcare concerns, concerns that are non-emergency cases.  Villagers will use cellphones to leave questions at a voice mail system running at the hub.  Being on the net, the hub machine is a part of a network of similar machines, housing a coherent distributed database, and allowing the hub staff, staff working elsewhere, or even our medical school volunteers in the US to "log on" and sort and prioritize the incoming queries, and record responses that are also stored in the database.  Operated by the hub staff, the hub machines compile relevant questions and responses and push them to the corresponding village base-station machines, which, at regularly scheduled times, pump the programs into the local FM transmitters. 

While the questions and answers in this case are prepared and played offline, we could also mix in live interactions (like the "chat room" scenario described above).  (Obviously, we do not expect a single question-answer exchange to provide the definitive panacea--instead, we consider this a first step to get people into "the system.")  Such community radio programs can also be linked to regularly scheduled physical visits by staff, who may pick up patients for further tests, or drop off medicines, or plan tailored awareness campaigns in relevant areas based on the information "mined" from the exchanges observed.  (We are also planning to link at least some of the callers into a distributed electronic medical record (EMR) system that we are building.)

An obvious reason for putting this kind of interaction on air (through a community radio system) is to get the community to participate: questions asked by one household may be of interest to a larger audience; except in the case of the system discussed here, the "audience" that we are talking about is not restricted to a single village--the "audience" could be the many villages participating in the entire "network," spanning a wide geographical distance, way beyond the several miles covered by a typical small community radio station. 

Another interesting aspect of this use case is the potentially heightened importance of a growing repository of previous communications.  If properly tagged and organized, the repository of previously aired programs could evolve into something like an "audio-Wiki:" in this way, one-time useful exchanges don't just disappear into thin air; instead, they can benefit subsequent queries at a different place or different time.  The modes by which the content accumulated in the repository can be used are many.  For example, in response to a frequently asked question, a hub operator (or even a village base-station operator) may simply search and retrieve a previous exchange that answers a similar or identical question.  If the new question warrants amending or refining of the previous exchanges, the operator may do so by flagging the current exchange for later editing and subsequent inclusion.  One may access at least part of the audio-Wiki by navigating phone menus (or SMS commands) and obtaining automated responses.  The audio-Wiki may also evolve beyond its audio format as, for example, hub staff produces video content that are based on the audio content.  Hubs specializing in some languages may choose to recruit volunteers or hire additional staff to translate selected relevant content available only in other languages in the database.


2. How is this different from a traditional "community radio"?


Perhaps the most succinct way of describing the differences is just one word: "Internet."  By that we mean that the way the system works, the kind of the applications that are enabled by the system, and the philosophy behind the system are inspired by and more similar to the Internet applications that we have grown accustomed to and love than those of traditional community radio systems.  In this section, we elaborate on these differences.

The "network effect"


For the most part, a traditional community radio station is a small isolated entity.  Its strength lies in its ability to produce and play highly localized content.  However, while ad hoc exchange of content with the "outside world" is possible, there is not a systematic linkage to "others just like you."  One may think of it as a small "Intranet:" while it could be very valuable in certain roles, in many other ways, an Intranet lacks the power and richness of the "Internet."

In the use cases discussed above, we have enumerated some examples of the good the outside world has to offer: collective wisdom of peer villagers elsewhere who might have struggled with exactly the same problems, outside experts, "memory" or "history" in the form of prior wisdom stored in a distributed knowledge database (the audio-Wiki).  The contributions flow in the other directions as well: the experiences and wisdom of this particular village could help others at a different place and/or at a different time.  At the same time, even as we include more people across a wider area in the system, we are not sacrificing the local relevance advantage of traditional community radio systems--we are not broadcasting one-size-fits-all content typified by mass-media: all the local broadcasts are still tailored and adapted and, indeed, are likely to include interactions directly involving the locals.

What we are discussing here is the "network effect," which needs to reach a certain "critical mass" for it to truly realize its potential.  Perhaps the network effect advantage can be best understood if we look at the audio-Wiki component of our community radio system: its construction is something that needs more than the participation of a few isolated villages, and once it reaches a critical mass of content, it may attract more to contribute and can benefit even more listeners.

Application themes

A basic idea underlying the proposed system is to enable interesting applications that are inspired by (or analogies of) today's Internet applications.  In other words, we are interested in imitating the Internet philosophy without mandating the PC-only or broadband-only infrastructure.  In the example use cases discussed in the last section, we have seen some of these application analogies and how they might work in the community radio-based environment: a "chat room," a voice mail system (behaving more like a mailing list system), and an audio-Wiki.  These are probably not the only application analogies and not the only ways to implement these analogies.  In the rest of this section, we discuss some common themes of these application analogies that make them different from traditional community radio stations.

  • Interactive and participatory processes.  This is referring to not only interactions between listeners and hosts, or listeners and "experts," but more importantly, also interactions among peers.  Getting kids from different villages to compete with each other on educational games is just one of the peer-participation examples.
  • Many-to-many communication.  While the figure at the beginning of this writeup might appear to imply some sort of hierarchical system, our aim is to actually enable something that's more like a cross-bar switch, something that enables anyone to "talk" to anyone else in the system.  This is in contrast to a traditional mass-media system where a very small number of experts "lecture" a vast non-responsive audience.  In addition to peers, for example, we may enable a volunteer sitting at home in the US, to be able to record something that is delivered to a village FM transmitter half a world away.  Our system is also very different from a traditional phone model, which is intrinsically a point-to-point system.  In contrast, a voice mailing-list system in our case allows the notion of "groups" to be defined and allows "messages" to be beamed to whole groups of listeners.
  • Asynchronous communication.  "Time-shifting" is perhaps as important as "space-shifting" in terms of conveniently delivering the most relevant information to the ones who need it.  The voice mail system and the audio-Wiki discussed earlier are important time-shifting tools.  This is in contrast to traditional radio call-in shows where the expert and the questioner must somehow agree to "meet" each other on-air at a specific appointed hour, a severe limitation.
  • A systematic and long-term memory.  In a traditional community radio station, due to legal requirements or due to the desire to reuse, the operator may choose to keep a record of recent broadcasts.  For the most part, however, these saved recordings, stored on tapes, CDs, or even hard disks, are ad hoc and scattered efforts, not easily accessible by a larger audience.  The web, on the other hand, did not rise overnight--it represents the cumulative wisdom of decades of work by many, work not just on production of new content, but work on systematic long-term storage and organization of existing content, all the while keeping everything accessible by everyone.  The audio-Wiki discussed earlier is an analogy of this sort, a way of providing long-term storage and organization.  (There could be other ways than the audio-Wiki to realize this analogy.)  Such an analogy should allow us to easily locate and retrieve relevant data from the long-term storage, and furthermore, should allow new content to be created that is based on the old content, and should allow meaningful linkages among all this content to be established.
  • Automated/programmatic response.  In a traditional community radio system, almost everything needs the station operator to be in the loop.  An operator can be a double-edged sword: on the one hand, they can play the role of a valuable facilitator or instigator; on the other hand, human elements such as the operator's imagination, his memory, his attention level could be a bottleneck that limits the potential of the system.  In contrast, a lot of the functionalities of the web are delivered to its users without human beings directly involved in the loop.  (Think "cgi-bin" scripts.)  This is a feature that we would also like to imitate to some degree in our system.  For example, the "chat room" example discussed near the beginning of this writeup could function without an operator.  The audio-Wiki example could potentially allow listeners to use a phone menu or SMS to choose or vote on what they want to hear.  Quizzes and educational games could potentially also be conducted in an automated fashion.  There may be other ways one may productively incorporate automated elements into a community radio system.  We should emphasize, however, our proposed system is never meant to replace humans: the villagers, the kids, the experts, the volunteers will always remain the most important players and the ultimate goal of the system is to connect them more effectively, not to replace them. 
  • Linkage to other networked systems.  In a simple example, imitating the concept of pen pals, we may link village children's voice mail box to, say, Gmail accounts of US-based volunteers and kid friends.  In a more involved example, we could link the proposed community-radio system with a patient record system that we are working on, so, for instance, automated reminders of children's immunization dates could be sent out on the air.

In the discussion of all these "themes," the community radio stations in our proposed system are meant to behave more as "output devices" of a far-reaching networked system, and with it, we hope to reap the benefits that may result from truly connecting those who have long been "outside the system."



project home                               © 2008    The Digital StudyHall