Serval Mesh Software-WiFi Multi Model Management Dr. Paul Gardner-Stephen

Swapna Palaniswamy

School of Computer Science, Engineering & Mathematics Flinders University Adelaide, Australia. +61427679796

School of Computer Science, Engineering & Mathematics Flinders University Adelaide, Australia. +61422047580

[email protected] ABSTRACT

[email protected] mode; Client mode; Mesh Potato; SSID; 802.11.

This paper describes the WiFi Multi-Modal Management component of the Serval Mesh Software. The Serval Mesh Software is a mobile telephony platform that can operate independent of fixed infrastructure, by using the WiFi capability of the device to automatically form a wireless mesh network that supports the carriage of voice calls, short messages and other modes of communication. Context and use cases for the Serval Mesh Software are included to provide the reader with some context. After describing the lack of inherent ad-hoc WiFi support on Android mobile telephones and the problems that result, this paper describes the WiFi MultiModal Management component incorporated into the Serval Mesh Software, that is used to maximize the mesh connectivity options available on any given model of telephone handset. The approach taken is to modularize the detection and control of the WiFi hardware on each model of handset so that support for new handsets can be added without recompiling the software or managing a single byzantine monolithic control script that contains the commands for all supported handset models. This modular approach is then leveraged to facilitate automated acquisition of WiFi ad-hoc mode on hitherto unsupported models of Android telephone handsets, removing the need for labor-intensive manual crafting of these scripts, and the bottleneck and infrastructuredependence that this previously entailed. The paper concludes with preliminary results indicating the success of the improvements to the Serval Mesh Software project described in this paper, including anecdotal reports from thirdparty users of the software.

Categories and Subject Descriptors C.2.1 [Computer-Communication Networks]: Architecture and Design – Wireless Communication.

Network

General Terms Design, Implementation, Documentation.

Keywords MANET; Serval Mesh; WiFi; Ad-hoc; Access Point; Monitor

1. INTRODUCTION The Serval Project[1] has created software, called Serval Mesh Software, which can be installed on Android based Smartphones. This software creates a Mobile Ad Hoc Network (MANET), which is also called a Serval Mesh that allows the Smartphones to communicate with each other. The goals of the Serval Mesh Software are to: 1) meet the communication needs of the people during emergency or disaster situations; 2) satisfy the basic mobile communication requirement of poor communities and isolated villages, and 3) utilize the potential of mobile communication to as great an extent as possible. The Serval Mesh Software works currently only on Android handsets, and operates using Ad-hoc mode. Unfortunately, the Android Operating System, (which has been developed by Google as an Open Source Operating System for mobile devices), does not support an Application Programming Interface (API), for Adhoc mode. This introduction focuses on use cases of the Serval Mesh Software, structure of the Serval Mesh, and the Serval Distributed Numbering Architecture, which is unique to the Serval Mesh Software for resolving telephone numbers on the mesh networks. The paper then proceeds to elucidate the use of WiFi by the Serval Mesh Software, explaining the issues faced, and the motivation that led to the creation of the WiFi Multi Modal Management material.

1.1 Use Cases The following are the use cases of the Serval Mesh Software, focusing on populations affected by disaster or emergency situations, poverty, or remote and rural populations.

1.1.1 Base of Pyramid Population According to the graph in Figure 1, this shows Mobile Cellular Subscriptions per 100 people globally, there is a huge difference in the subscriptions between so-called developed countries, and the less developed countries. This is because, in the least developed and developing countries, many cannot afford to pay for the subscription to mobile phone carriers, or because of lack of service in their area. Thus mobile communication is still a relatively unattainable goal for many people in these situations. The Serval Mesh Software seeks to provide an effective solution for this so-called “base of Pyramid Population”[2] , a term used to describe the majority of the world population who earn the lowest incomes. They would be able to create a local mesh network by installing Serval Mesh Software on Android based

via satellite services, such as BGAN terminal couples to a suitably configured Mesh Potato[2].

Mobile Cellular Subscriptions per 100 inhabitants

Per 100 inhabitants

120.0 100.0 80.0

Developed

60.0

World

40.0

Developing

20.0 0.0 2000

2001

2002

2003

2004

2005

2006

2007

2008

2009

2010

Year

Figure 1. Mobile Subscriptions per 100 people[11]. handsets, and communicate within the mesh for no cost beyond the initial outlay of the handset - which may be overcome by recycling unwanted First World hardware when appropriate (which also helps reduce the growing E-Waste issue). The situations envisaged also include those of displaced persons in refugee camps, and other crisis type scenarios. The Village Telco’s Mesh Potato[3] can also be used with the Serval Mesh Software to provide a fixed and as well as a mobile mesh telephony installation. Such installations would provide, at the very least, the basic communication requirements.

1.1.2 Disaster and Rescue Purposes There have been several high profile recent (natural) disaster events such as the earthquake at Christchurch, New Zealand and the tsunami at Fukushima, Japan. The need for mobile communication is not only to provide information to, and call for assistance from, rescue services. It is also increasingly relied upon to communicate with family and friends, to provide reassurance of safety, or to inform about present conditions & location. However fixed land line, and mobile telephone services might be unavailable, or even unusable, as infrastructure might be damaged or completely removed during the disaster, or even overwhelmed by the surge in demand during such events - including emergency services requiring access to reliable telecommunications. The Serval Mesh Software[2] can help in these situations because it does not rely on infrastructure, and because it can handle large local call volumes. Importantly, the Serval Distributed Numbering Architecture also allows users to retain their existing phone number on the Serval Mesh, allowing people to communicate with their circle of family and friends unimpeded by complications due to undiscoverability of contact details.

1.1.3 Remote or Rural Area Population There are many remote areas where there is marginal coverage or no coverage of the cellular network. For example, rural settlements such as Basked Range lack cellular coverage, despite being located less than 15km from Adelaide, the fifth largest city in Australia. Cellular network service providers may not be able to consider raising tower in those locations as it may not be economically feasible: the low population means insufficient subscribers to meet the installation and maintenance costs of the towers. Serval Mesh Software[2] provides a potential solution to these issues by allowing the formation of networks without expensive infrastructure. It is also possible to create gateways between a Serval Mesh and cellular networks by placing a single suitably configured handset running the Serval Mesh Software in a position that is reachable to the cellular network, with calls within the local Serval Mesh remaining free of carrier involvement or cost [2]. In areas where there is no cellular service, the Serval Mesh software can be similarly gated to the public telephone network

1.2 Overview of Serval Mesh & Serval Distributed Numbering Architecture (DNA) The Serval Mesh software currently uses the BATMAN[4] routing protocol to allow 802.11 devices in ad-hoc mode to communicate with the mesh. This protocol was chosen because of its proven performance in the Village Telco’s initial Mesh Potato[3] deployments. The Mesh Potato[3] is a device that provides low cost telephony operating in the Access Point mode also capable of participating in the mesh. The core mesh and telephony functions of the Serval mesh software are inherited from this device. Each Mesh Potato is assigned an IP address; the call is then established by the caller dialing the IP address of that particular callee’s device, which is translated into a SIP address, the call then connecting via an Asterisk instance embedded in each Mesh Potato. The Serval Distributed Numbering Architecture (DNA)[2] is responsible for call establishment in the Serval mesh software, and uses the same call connection process but, it allows the resolution of ordinary telephone numbers to SIP address. Thus users can use their existing telephone numbers instead of having to dial by IP address. Because of this similarity in the core calling process, the mesh potato and the Serval mesh software are compatible with each other. Serval DNA operates with the phone selecting a random 256-bit Subscriber ID (SID). The SID is associated with one or more user selected Direct-Inward Dialing Numbers (DID) i.e.., ordinary telephone numbers. An example DNA number resolution is shown in Figure 2, where the caller broadcasts the telephone number request to all phones in range, and then one of those responds with it’s SID and SIP address where the call can be placed. More generally, when the caller (A) dials the DID number, the phone broadcasts the number and receives responses i.e., the SID and SIP address associated with that particular number from other phones on the mesh. There are three cases that can happen 1) No responses are received, and the call is not established, and the user is informed that the destination is unreachable. 2) One response is received, and the call is connected via Asterisk, subject to an identity check. 3) More than one response is received, in which case the identity check must provide disambiguation. The identity check verifies whether the responding SID(s) are trusted by the caller as the accepted claimant of the dialed number, by consulting a stored list of trusted SID:DID pairings. If the result is positive, the call proceeds without user interaction. If there is no record of the pairing, or if there is a pairing with a different SID, then the user should be warned about the unconfirmed identity status, allowing them to make the final decision as to whether to connect the call. The SID should be the public key as in the asymmetric public key cryptography, such that man-in-the-middle attacks can be prevented, and Diffie-Hellman key exchange[12] can be used to encrypt and authenticate traffic between the two parties. An extension to the call resolution process is that each device in the mesh can act as a gateway and can respond to number resolution requests with SIP addresses. The other end of the gateway can be another mesh between which the device can act as

a bridge. Alternatively, it can be a gateway to a VoIP (Voice Over Internet Protocol) provider, allowing calls to and from the mesh.

support for new handsets in the field, as it requires access to a full Android software development environment; something that is not possible to provide on the phone itself, thus introducing a dependence on external infrastructure, something that is an anathema to the Serval Project's philosophy. Moreover, it makes it impossible for the software itself to make and test educated guesses about how to control the WiFi hardware on a given handset, thus denying the opportunity for the software to deduce how to control the WiFi hardware without reference to any external infrastructure or party. This is of particular relevance given the recent explosion in variety of Android handsets, and thus is given attention in this paper. Therefore the detection code must be broken out into an appropriate scripting language, and the WiFi control edify script must be broken down into individual scripts for each model of handset. Only then can support for new handsets be easily added in the field.

Figure 2. Simple Call Resolution Using Serval Distributed Numbering Architecture.

The Android WiFi Tether also fails to provide a high-level API that would allow other applications to access and manipulate WiFi ad-hoc operation. While we are not aware of any need beyond the Serval Project, it makes sense that the effort expended in gaining control of the WiFi hardware be made available to other potential users - after all, it is the omission of such an API that has precipitated the work embodied in this paper.

1.3 WiFi on Mobile Phones All WiFi enabled smart phones support client or managed mode, which is the ordinary mode of operation where WiFi devices associate with an access point. The Android OS version 2.2 (Froyo)[6] added support for soft access point mode, which would potentially allow phones in client mode to associate with them, but with the limitation that phones in access point mode cannot communicate with other phones in access point mode. For fully infrastructure-free operation one must use ad-hoc mode. However, Android does not provide an API support for ad-hoc mode. The Android-WiFi-Tether (AWT) program was created to partially address this problem to allow wireless tethering of laptops to the cellular data service of an Android phone[5]. This open source program was used as the initial basis for obtaining ad-hoc mode for the Serval mesh allowing substantial reuse of effort. However, AWT’s approach has a single script in the edify language that controls the chipset manipulation, and the actual detection of chipsets residing in the Java portion of the program. This makes the software difficult to extend to support additional models of Android phone, and in any case requires recompilation, thus precluding in-field expansion of the list of supported handsets. Also, AWT does not provide an integrated interface for switching among these three modes of operation. These facts prompted the idea of creating up a single WiFi Multi-Modal Manger that can detect and switch among the available modes on a given device from a single point, as well as making it easier to add support for ad-hoc mode on additional handsets without requiring a full software update.

All means of obtaining ad-hoc operation on Android require root access, including those proposed in this paper, and even with root access there remains the possibility that for any given model of handset is that not possible to control the WiFi chipset, perhaps because support for that configuration has not been deduced automatically or researched. While ad-hoc mode will be available in many instances, there remains the challenge of how to facilitate participation in a mesh network in the absence of the availability of ad-hoc mode. This requires exploration of the mutual communicability of devices in various WiFi modes, and the exploration of schemes that allow communication of devices that lack ad-hoc mode support. Prototypical solutions are presented in this paper to demonstrate the feasibility of such schemes.

3. METHOD The section discusses the various WiFi modes, including the modularized approach to handset auto-detection being introduced by this paper, the availability of the various modes and usefulness in supporting a Serval mesh, before discussing their mutual intelligibility, initial WiFi mode cycling strategies and the exploitation of modularizing the handset detection and control scripts to enable automatic detection of ad-hoc WiFi control on a subset of models of handset.

2. OBJECTIVES

3.1 Client Mode

The goals of the WiFi Multi-Modal Management component are: 1) to be able to easily add support for a new handset without having to re-compile and re-install the software; 2) to have a highlevel API for our Android application that supports ad-hoc mode as well as the modes supported by the Android OS; and 3) For the Serval Mesh Software to be able to connect to other devices when ad-hoc mode is not available, e.g. if the phone is not supported. Related to this is the need to maximize connectivity with other devices by managing and appropriately sequencing through the available WiFi modes to interact with whichever mode the other devices may be using. These objectives are expanded below.

The Client mode is the default mode in which the mobile phones operate in order to communicate with WiFi access points. Therefore, this mode is supported in the Android OS. It does not require root access to set this particular mode therefore all smart phones can function in this mode. Hence, even a phone that does not provide root access can still connect to the Serval mesh by using client mode.

3.2 Access Point Mode in Froyo-Android OS version 2.2

The organic growth of AWT and use of pre-compiled Java code for handset detection is particularly problematic for adding

Android[7] is a open source platform designed for developing mobile applications. It uses Java for programming and the handset

runs on a Linux platform upon which the Android applications are executed. In specific, the Android application runs on its own virtual machine. Before the Android OS was released, each mobile phone had its own Operating System and the development code of the applications is always hidden to the outside world. Therefore, the mobile users only had the opportunity to use the applications that came along with the handset. With the Android OS in the handset, the software developers can now code innovative mobile applications. They can choose to develop freeware, shareware, or trial-ware applications, ad- driven and paid applications; distribute them through number of ways. Google has its own generic Android application store to with a revenue-sharing model. It hosts the Android open source project and provides online Android documentation, tools, forums, and the Software Development Kit (SDK) for developers. Each SDK versions has improvements over its predecessor. The Android SDK version 2.2 (Froyo)[6] allows the Smartphones to turn on the Wi-Fi hot spot. With this application the mobile phone operates in the Access point mode and creates a WiFi hot spot that enables up to eight devices such as mobile phones, PDAs and laptop to connect to the hot spot. It gives the options to modify the Wi-Fi encryption settings, alter SSID settings, change the WiFi frequency channel, enable Access Control and modify Notification settings. With the help of this application, it makes it easy to create Personal Wi-Fi hotspot without making any major changes in the code. Therefore, if the mobile has the corresponding Android version 2.2 then it can potentially support the Access Point.

3.3 Ad-hoc Mode & Chipset Detection The Serval project began by using AWT to access ad-hoc mode on compatible handsets. This application supports only a limited list of handsets. Moreover, the structure of the code was not scalable as it was a single long and relatively complex edify script that contained all chipset control commands for all handsets. The actual detection of the handsets was hard-wired into java code which tested for the existence of various files and system properties that enabled the differentiation among various models of handset.

Figure 3. Device Chipset Detection. The ability for the software to write and then use new scripts while running is exploited later in this paper. The Figure 3 shows how the detected device chipset is being displayed in the WiFi Settings of the Smartphone running the Serval mesh software. The drop down contains all the chipset that can be detected by the software. If the user’s phone is not detected as one of the supported models, the software gives the option to pick one of the values from the dropdown list to check if the phone is compatible with the selected scripts.

3.4 Mapping Mutual Intelligibility of WiFi Modes A compatibility table was developed to understand the

The edify script was broken down into separate scripts for each supported handset, and further divided into the commands required to start and stop ad-hoc mode. The resulting scripts are now on average only nine lines, and much easier to comprehend. The embedded handset detection code was analyzed, and a simple unnamed scripting language created that enabled each of the tests previously hard-wired into the Java code to be expressed in a short script. These scripts average a mere three lines. These measures render it possible to update the list of supported handsets by downloading a very small amount of data. Indeed, all scripts for the 17 currently supported handsets can be compressed to less than 4KB. Such a download need not be from the internet, but could in principle be from another phone on the mesh, if the two phones are able to communicate, for example, by temporarily switching to client and access point mode respectively, thus adding further impetus for the implementation of appropriate mode cycling strategies.

Figure 4. Compatibility of different WiFi Modes. interoperability of different modes[8] and their combination. For all reasonable purposes this can be summarized as: 1) clients devices can communicate with access points devices, and viceversa; 2) ad-hoc devices can communicate with other ad-hoc devices; 3) devices that can also enable monitor mode can hear

traffic from all other devices, but not communicate with them; and 4) other devices cannot communicate. The Figure 4 presents the possible combination of the four modes (client, access point, ad-hoc and monitor) and the interaction between these modes. Some WiFi chipsets are indeed capable of operating in multiple modes simultaneously, a possibility that is not explored further in this paper, but may be a fruitful area of exploration in maximizing connectivity of devices.

3.5 Automatic Cycling of WiFi Modes The cycling strategy was basically built, considering four modes: 1) ad-hoc; 2) client; 3) access point; and 4) off, as a meta-mode. The reason for choosing the above modes is because it seemed to be practically possible to implement the above modes on Android handsets, and that these were sufficient to allow mutual communication among all devices, although not necessarily at the same time. The focus of the current effort was on creating the framework for the cycling, rather than optimizing the cycling strategies themselves, which is an area for future work. Thus, somewhat arbitrarily the default cycling strategy was chosen as spending approximately 30 seconds in each active mode before advancing to the next, but only if no peers are located. If peers are found in a given mode, then the phone will remain in that mode. This is suitable for initial experimentation, but is subject to lock-step and anti-synchronization issues, which will need to be addressed in future releases.

supported by the Serval Mesh Software, thus establishing the value of this approach in automatically adding support for new handsets in the field -- all without reference to any supporting infrastructure either physical or organizational, and saving considerable work on the part of the Serval Project team to handcraft support scripts for each new model of handset.

4. RESULTS & DISCUSSIONS Figures 4 and 5 show screenshots of the Serval Mesh software running on the Huawei IDEOS U8150. Figure 4 shows the mobile is currently operating in Ad-hoc mode and the user can change the mode by selecting it from the drop down list, which displays the WiFi modes supported by this phone. Figure 5 shows that the mobile is currently operating in Ad-hoc mode, and the user has chosen automatic mode cycling. This will automatically cycle between the potential modes of that particular phone. When the phone is working in Access Point mode, a tethering icon is displayed on the top status bar, along with the Serval icon (that can be seen in Figure 6. It also shows that there are three peers currently connected to that phone. The use of client mode allows even a non rooted phone to get connected to the Serval Mesh, as shown in Figure 7, where the Samsung Galaxy Ace has the Serval Software successfully installed and working in the client mode to get connected to the Serval Mesh via a node that is operating in access point mode which is shown in Figure 8.

3.6 Automatic Detection of WiFi Chipset Adhoc Control The modularized chipset detection and control scheme described above creates the necessary environment to allow just-in-time detection of the means to detect and control the chipset hosting a running instance of the Serval Mesh Software, by having the software write the detection and control scripts and then attempting to use them to control the WiFi chipset to access adhoc mode. This opportunity was exploited by examining the contents of the detection and control scripts that were derived from the monolithic and integrated detection and control process in that program. This was supplemented with writing software that explored the operating system installed on the phone on which it is running to find any scripts, kernel modules and other artifacts that provide clues as to how to manipulate the WiFi chipset. The quality of these clues varies. On some handsets there are scripts that use the insmod command to load the WiFi chipset driver. On others, a wifi.conf file exists that provides adequate information to formulate the insmod command required to load the WiFi chipset driver. Some handsets have misleading information, or scripts suitable for more than one chipset, perhaps as artifacts from the handset development process, as in some instances they appear to be rather generic in nature. These clues were then used to generate on or more educated guesses as to how to control the WiFi chipset on the phone. Once the guesses have been generated they are tested each in turn, using iwconfig to verify whether the particular instructions are able to activate ad-hoc mode. Some of the handsets that were able to be automatically detected and controlled using this approach, include the Samsung Galaxy S2 and Motorola Atrix, were not previously

Figure 5. User Selection of Mode. The Table 1 displays comments from users who have installed the software, via the Android Market[9].This can also be downloaded from the Serval project’s web page[10]. The comments illustrate that people not connected with the research team have been able to use the chipset control auto-detection feature described in this software. It shows the phones that have been commercially used for installation of the software. The most popular handset seems to be Samsung Galaxy S.

Figure 8. Samsung Galaxy Ace Operating in Client Mode. The code has been successfully implemented and tested on Huawei U8150 IDEOS phone. Other older Android phones have had varied rates of success in testing in the laboratory, due to the wireless chipsets and other hardware variations. Feedback is also coming in from various handsets, as the software has been released as a prototype to the broader developer community for testing.

Figure 6. Automatic Cycling Mode enabled.

Although the Serval software works well with the recommended model of phone, it frequently encounters problems with other Android phones, which is a not unexpected effect of trying to get a diverse range of devices to perform a significant new function. Early adopters are encouraged to join the serval-projectdevelopers, and also to notify and track bugs in the project bug tracking software online, so that it can be fixed by the developing team, or by volunteer open source developers interested in assisting with the project Table 1. Comments from the users in the Android market 1.

` Figure 7. Huawei phone Operating in Access Point Mode. Feedback has indicated that some phones, such as Samsung Nexus One, seem to encounter problems such as the application crashing when trying to select different modes from the drop down list, perhaps because many different Android distributions and versions are available for that phone. Work continues on refining the auto-detection process and general software to reduce these problems.

2.

Sample Comments from the Android Users “I have installed and made my first call between zte blade cm7 and T-Mobile pulse mini in less than a minute. Good work guys”. “An app worthy of praise The aims of the Serval Mesh project should be supported. Visit the project website for full info. As Android users tend to be more tech-minded, I hope people will try the app and give useful feedback to the devs. For me, I have it on a Hero and a NexusOne, communicating, sort of... :)”

5. CONCLUSION AND FUTURE DIRECTIONS We conclude that WiFi Multi Modal Management system has been successfully prototyped. The future progress will include the effort to deploy it in the manufacturing stage of the Android Handsets. This way it facilitates ease of use, it also reduces the overhead of downloading and installation. From the use cases, it is obvious that it definitely provides a positive outcome for humanitarian efforts, and global communication, regardless of

financial status, remote location, or dire emergency. This is one of the primary motivations of the Serval project. Future directions of this project will include: 1) exploring better mode cycling strategies to avoid anti-synchronization issues; 2) expanding the range of support handsets, including through the enhancement of the auto-detection process; and 3) generally improving the Serval Mesh software, and incorporating various other features that are being worked on, including a distributed short message service, Serval Rhizome mesh-based data distribution, video streaming, and mapping services that are all being actively developed. The Serval Project team is also preparing to undertake a series of trials that will gather much needed field data on the usability of the software, which is expected to lead to an ongoing technology enhancement program.

6. ACKNOWLEDGEMENTS The authors would like to acknowledge the financial support of the Awesome Foundation (Boston Chapter), the NLnet Foundation, Flinders University and the Shuttleworth Foundation.

7. REFERENCES [1] P. Gardner-Stephen, "Sustaining Telecommunications Capability and Capacity during Acute Phase of Disasters and Disaster Response." pp. s101-s102. [2] P. Gardner-Stephen, "The Serval Project: Practical Wireless Ad-Hoc Mobile Telecommunications," http://developer.servalproject.org/site/docs/2011/Serval_Intr oduction.html, [30 th August, 2011].

[3] M. Adeyeye, and P. Gardner-Stephen, “The Village Telco Project: A reliable and practical wireless mesh telephony infrastructure.,” EURASIP Journal on Wireless Communications and Networking, vol. In press., 2011. [4] D. Johnson, N. Ntlatlapa, and C. Aichele, “Simple pragmatic approach to mesh routing using BATMAN,” 2nd IFIP International Symposium on Wireless Communications and Information Technology in Developing Countries, CSIR, Pretoria, South Africa, 6-7 October 2008, 2008. [5] "android-wifi-tether," 30th August, 2011; http://code.google.com/p/android-wifi-tether/. [6] "Android 2.2 Platform Highlights," 20 the August, 2011; http://developer.android.com/sdk/android-2.2highlights.html. [7] C. Shane, and D. Lauren, Android Wireless Application Development, Second Edition ed.: Pearson Education, Inc, 2010. [8] I. F. Akyildiz, X. Wang, and W. Wang, “Wireless mesh networks: a survey,” Computer Networks, vol. 47, no. 4, pp. 445-487, 2005. [9] "android market," 26th August, 2011; https://market.android.com/publish/Home#ViewStatisticPlac e:p=org.servalproject. [10] "serval:uniting the world through communication," 28th August, 2011; http://developer.servalproject.org. [11] "International Telecommunications Union," 30th August 2011; http://www.itu.int/ITU-D/ict/statistics/. [12] W. Diffie, and M. E. Hellman, “New Directions in Cryptography,” IEEE Transactions on Information Theory, vol. IT-22, NO. 6, November 1976.