Mobile Learning Platform Connected to Moodle using J2ME

—This paper presents a mobile learning platform (MLP) connected to a Moodle course management system build, using the Java2 Micro Edition (J2ME), developed in our Mobile Multimedia and Wireless Communication Lab (MMWCL). The MLP uses wireless communications (Bluetooth, WI-FI, WIMAX) to connect with the Moodle server. Later, after the connection is established with the server, the J2ME application will be able to provide the user with a bundle of services. These services include grades, course schedules, attendance records, course announcements, and university activities, as well as quality assessments.

INTRODUCTION Mobile learning has different interpretations by several communities. The distinct interpretation is in its focus on learning across contexts and learning with handheld or portable devices. Thus, mobile learning decreases limitation of learning location with the mobility of general handy devices.
Learning with portable technologies, where the focus is on the technology ; learning across contexts, where the focus is on the mobility of the learner, interacting with portable or fixed technology. Because most students today have some sort of internet-enabled mobile device (3G cell phone or PDA, smart phone), Mobile Moodle provides these users with fast, straightforward access to their academic lives. Mobile Moodle has space for greater applications tailored to its strong points. For example, it has the possibility of sending notifications to the user whenever the course's professor makes certain announcement, therefore notifying students of things such as course cancellations or room changes without risking the students not checking Moodle on their own.
Mobile learning consists of the following entities. 1) Authoring and publishing (Course design and manipulation) 2) Delivery and Tracking (Communication channels and Application) 3) Content Development (Course Management) Common observation states that over the past ten or so years mobile learning has grown from a minor research interest to a set of significant projects in schools, workplaces, museums, cities and rural areas around the world.
Delivering learning materials over wireless is an important component of many interactive mobile learning applications running on personal wireless handset devices. Such personal devices have to be inexpensive, compact, and lightweight. But wireless channels have a high channel bit error rate and limited bandwidth. Delay variation of packets due to network congestion and the high bit error rate greatly degrades the quality of video at the handheld device. Therefore, mobile access to learning contents requires general platform at the edge of the mobile network for inter-working with heterogeneous networks and services. Hence, this paper first introduces the means for delivering the learning content then examines the challenges and limitations to organize the material itself in semantic manner. Then handheld resources, network conditions and content based are proposed.
Current advances in mobile communications and portable client devices enable us to access multimedia content universally. However, when multimedia content becomes richer, i.e., including video and audio, it is difficult for wireless access to communicate due to the existence of many restrictions. The most important factor of all, wireless connections usually have a much lower bandwidth compared to wired ones. And communication conditions change dynamically due to the effect of fading in wireless communication. Another important factor is that portable client devices are equipped only with limited computing and display capabilities, which are not suitable for high quality video decoding and displaying.
Concerning the heterogeneity issue, the previous era has seen a variety of developments in the area of multimedia representation and communication. In particular, we are beginning to see delivery of all types of multimedia data for all types of users in all types of conditions. In a diverse and heterogeneous world, the delivery path for multimedia content to a multimedia terminal is not straightforward, especially in the mobile communication environment. Access networks are various in nature, sometimes limited, and differ in performance. The characteristics of end user devices vary increasingly ( over the recent years), in terms of storage, processing capabilities, and display qualities; also, the natural environment changes: changes in position, elucidation or temperature; finally, users are different by nature, appreciating dissimilar preferences, special usage, disabilities, etc.
The advance of multimedia systems has had a major influence in the area of image and video coding. The problem of interactivity and integration of video data with computer, cellular, and television systems is relatively new and subject to a great deal of research world wide. As the number of networks, types of devices, and content representation formats increase, interoperability between different systems and different networks is becoming more important. Thus, devices such as gateways, multipoint control units, and servers must be developed to provide a seamless interaction between content creation and usage.
The transporting of content over wireless channels to mobile users is becoming a research topic of rapidly growing interest [14,15,16,19,20]. With the emergence of small wireless handset devices such as PDAs, and video mobile and so forth, it is expected that interactive multimedia will be a major source of traffic to these handset devices. These devices could be carried by users inside buildings when they are connected by wireless LAN or in vehicles when they will be connected to the cellular network, such as GPRS [10,13]. As well as, Wideband mobile communication systems such as IMT-2000 have emerged, and there should be a mechanism to cope with a variety of media such as video provided to mobile terminal.
Wireless transmissions use radio channel as the transmission media. Generally, radio links connect users to base stations. The base stations in turn, are connected to routers using wired links. The wireless segment "cells" provides mobility to a user while using the network. In contrast to wire-line transmission links wherein the bandwidth can be easily increased and the channel quality can be guaranteed, whereas the bandwidth of a wireless channel is limited because of spectrum allocation and physical limitations. The transmission quality of radio is easily affected by environments such as buildings, moving objects, and atmosphere, shielded obstacles and so forth. Moreover, because of the mobile nature of the users, the access point of a mobile user changes continuously. All these factors in wireless networks give rise to issues such as effective bandwidth allocation, channel with high bit error rate, and user handover.

Wireless Wide Area Networks:
After the firstgeneration analog mobile systems, the second-generation (2G) mobile digital systems were introduced offering higher capacity and lower costs for network operators, while for the users, they offered short messages and lowrate data services added to speech services. An important evolution of the 2G systems, sometimes known as 2.5G, is the ability to use packet-switched solution in GPRS (General Packet Radio System). The main investment for the operators lies in the new packet-switched core network, while the extensions in the radio access network mainly is software upgrades.
The shift to third-generation in the radio access networks is the result of demanding a much more better performance. The third-generation addresses areas such as user bandwidth, richness of service offerings (multimedia services), and flexibility (networks that can support small or large numbers of subscribers  [11,17,18,21,22] is a wireless industry coalition whose members organized to advance IEEE 802.16 standards for broadband wireless access (BWA) networks. WiMAX 802.16 technology is expected to enable multimedia applications with wireless connection and, with a range of up to 30 miles, enable networks to have a wireless last mile solution.
Wireless Personal Area Networks: A WPAN (wireless personal area network) is a personal area network -a network for interconnecting devices centered around an individual person's work space -in which the connections are wireless. Typically, a wireless personal area network uses some technology that permits communication within about 10 meters -in other words, a very short range. One such technology is Bluetooth, which was used as the basis for a new standard, IEEE 802.15.
A WPAN could serve to interconnect all the ordinary computing and communicating devices that many people have on their desk or carry with them today -or it could serve a more specialized purpose such as allowing the surgeon and other team members to communicate during an operation.
Bluetooth: Bluetooth [12] is a high-speed, low-power consuming microwave wireless link technology, designed to connect phones, laptops, PDAs and other portable equipments together with little or no work from the user. Unlike infrared, Bluetooth does not require line-of-sight positioning of connected units. The technology uses modifications of existing wireless LAN techniques but is most notable for its small size and low cost. Whenever any Bluetooth-enabled devices come within range of each other, they instantly transfer address information and establish small networks between each other, without any instruction from the users. To a large extent, Bluetooth have motivated the present WPAN attempts and conceptualizations; moreover, it constitutes the substance of the IEEE 802.15.1. WPAN standard.

III. ISSUES OF VIEWING CONTENTS IN A MOBILE
ENVIRONMENT Although the constraints imposed by the heterogeneous nature of the communication network are quite different from those arising from the diversity of user terminals, both of them may deal with transcoding systems.
Mobile-device users often wish that they could access the variety of rich video and audio content that exists or will exist on video servers. However, these devices constrained computational and rendering power and cellular networks limited bandwidth, effective video content presentation will require new computation patterns. The mismatch between rich multimedia content and constrained client capability presents a research challenge.
The variety in mobile devices also increases the difficulty of accessing content. For example, mobile devices are conveniently sized to fit in a pocket, but this size constrains their display area. Creating arbitrary trimmed versions of content could get around this constraint, but differences in display capabilities would easily make a device-specific authoring approach too costly to be practical and lower quality of service in some cases.
Examples of device differences include screen sizes ranging from few hundred to thousands of pixels, and color depths ranging from two line black-and-white display to full-color display. In these cases, transcoders can be used to transform multimedia content to an appropriate video format and bandwidth for wireless mobile streaming media systems. However, a typical CCIR601 MPEG-2 video requires almost all the cycles of a 300Mhz CPU to perform real-time decoding. This scalability is critical to enable wireless networks to handle user requests that may be very intense at high load times.
In this section we identify issues involved in viewing a learning video stream in a mobile computing environment and propose methods of handling these issues. Video streams encoded by a high-bit-rate compression method (e.g., MPEG-1) require several megabits per second of bandwidth and are not suitable for a strictly band-limited environment. Therefore, video streams should be encoded by a low-bit-rate compression method (e.g., MPEG-4). MPEG-4 is appropriate for mobile access because it is robust to channel errors. From this point of view, some MPEG-4 codec large-scale integrations for mobile devices are under development, and MPEG-4 is apparently becoming the mainstream technique for mobile video usage. When communication conditions get worse and error rate increases in a wireless link, transmission jitter increases because error packets are retransmitted based on Radio Link Control protocol, located at the data link layer. If any packets are not recovered by retransmission, using a reliable transport protocol such as Transmission Control Protocol (TCP), error packets are retransmitted end to end. Consequently, this causes more transmission jitter and throughput reduction. Also, if an unreliable transport protocol such as User Datagram Protocol (UDP) is used, packets not recovered by retransmission and flooded by congestion on the communication link will be discarded, so the rate of packets that arrive at the client decreases. As a result, in both cases the application layer throughput reduces, and video data cannot be transferred stably. Therefore, the data rate of a video stream needs to be adapted in accordance with communication conditions. In addition, jitter can be absorbed by preserving some video data on the client buffer. As far as client device capabilities are concerned, display size, processing power, and memory size have to be taken into account. Since the display size of portable devices is small (on cellular phones both width and height are about 100 pixels at most), a video stream may be larger than the display size and is not easily viewed by mobile users. Hence, both the width and height of a video frame have to be fitted to the display size. In another method, the size may be reduced on the user client. However, it places an extra load on the user client and is undesirable for mobile where the processing power of the client device is low. If the client device does not have enough real-time video stream decoding power, a mobile user cannot fully view video streams. The amount of processing required for decoding is related to the number of video frames in one second (frame rate) and total number of pixels in one frame (frame size). Therefore, the frame rate and frame size need to be adjusted according to the processing power of the client device. As for memory size, the client device needs to have sufficient memory to preserve several decoded frames because, in encoding methods such as MPEG-4, the decoding process requires a few frames before and after the frame which is actually being decoded.
IV. GENERAL SCHEME The platform is composed mainly of three components: the J2Me application, the interface between the J2ME application and the Moodle server, and finally an instance of Moodle Course Management System (CMS) server for back-end support and integration The previous Figure 1, states clearly the system overview of the proposed MMLP. The mobile "handheld" device is composed of group of J2ME application that is designated to connect to CMS-J2ME application server to attain the provided services. The provided services include: • The second component in our system is shortly an interface to match between the mobile applications and the Moodle server. This component is in charge of translating the mobile application requests into suitable format for Moodle CMS. This component will consist of several Java servelets to serve as intermediary. The last component is predefined and updated moodle CMS that is developed in [2]. The Moodle CMS is usually connected to back-end database to support its functions.
Various optimization techniques [3] are applied on the mobile application in order to attain a good amount of mobile limited resource utilization. In addition, a novel technique is conducting to achieve high percentage of load balance [4] on the CMS side. The load balance will guarantee a high degree of robustness and stable behavior for the whole platform give the great amount of users (students) who are using the MMLP.
A pilot study is conducting to measure the efficiency of the proposed system. Expected results are to support our basic provided service usability and importance. In addition, a comparative study is taking place to cross examine the platform end-to-end efficiency.

V. MOODLE COURSE MANAGEMENT SYSTEM (CMS)
A Moodle CMS can be useful for a wide variety of reasons. These include something as simple as storage of electronic course notes or links for later use all the way to a full-blown asynchronous learning site. The following are some features of Moodle Course Management System [2]: • Teacher has full control over all settings for a course. • Choice of course formats such as by week, by topic or a discussion-focused social format • Flexible array of course activities -Forums, Quizzes, Resources, Choices, Surveys, Assignments, Chats, and Workshops. • Recent changes to the course since the last login can be displayed on the course home page -helps give sense of community • All grades for Forums, Quizzes and Assignments can be viewed on one page, and downloaded as a spreadsheet file. • Full user logging and tracking -activity reports for each student are available with graphs and details about each module (last access, number of times read) as well as a detailed "story" of each students involvement including postings etc on one page. • Mail integration, copies of forum posts, teacher feedback, etc can be mailed in HTML or plain text. • Custom scales -teachers can define their own scales to be used for grading forums and assignments • Assignments can be specified with a due date and a maximum grade. • Students can upload their assignments (any file format) to the server -they are date-stamped.
• Teacher feedback is appended to the assignment page for each student, and notification is mailed out.  Figure 2: system interface, system application, and database management system (DBMS). The system interface layer handles how the client WAP browser interacts with the application. The system application layer handles authentication, course information content and course communication content delivery. The DBMS layer stores and manages the course information content (such as, course syllabus, materials, assignments, tutorial, labs, and grades), communication content (such as, SMS, email, chat, useful links, student testing and grading), student and teacher profiles. The system architecture consists of three components: the client, the server, and the DBMS. The client side application, which developed by PHP, WML, and XMLbased tools. The server application, which developed by PHP, ASP.NET, ASP.NET mobile controls, and C#.NET. It acts as a gateway between the database and the clients. The ASP.NET mobile controls render the appropriate markup (HTML, WML, cHTML, XHTML) while dealing with different screen sizes, orientations and device capabilities. The course information contents is stored and managed using MySQL database. The database and the server applications will run on Microsoft Windows Server.
The Extended Markup Language (XML) has been selected for specification and development of the Mlearning system. In the following sub-sections we introduce an overview of XML model, and show how we can use XML for information exchanging .

A. The XML Model
An XML document consists of three parts: an XML declaration, a DTD (Document Type Definition) or XML Schema, and an XML instance (XML document data). An XML declaration and Schemas are not mandatory for an XML document. An XML declaration specifies the version and the encoding of XML being used. A DTD or XML Schema is a schema that constrains the structure of XML instances, and corresponds to an extended contextfree grammar. An XML instance is a tagged document. XML documents have two levels of conformance: valid and well-formed. A well-formed XML document follows tagging rules prescribed in XML. An XML document is valid if it is well-formed and if the document complies with the constraints expressed in an associated schema.
Definition (XMLTree): An XML document can be viewed as a tree, where leaf nodes correspond to data values (text) and internal nodes correspond to XML elements [7].

B. The DOM Model For XML Documents
The Document Object Model is an object model to represent XML documents and an interface to work with that model. It gives a tree overview of all XML elements and how they relate to one another. It is a good model for handling XML documents because it takes the tree like model of XML as its core idea and makes no presumptions about the structure of the document [8].
Definition (XDTree): We model an XML document D as an XML DOM document tree (XDTree) T, in which nodes represent XML elements and edges represent parent-child relationships between XML elements. For each XML element node e∈ T, we use the following notations: • e.name: the name of the XML element.
• e.parent: the parent node of e, and e.parent = NULL, if e is the root node of T . • e.children: the set of children nodes of e, and • e.children = Φ if e is a leaf of T. We also denote • the children of e by: e.c 1 , · · · , e.c m . • e.attributes: the set of XML attributes of e. We also denote the attributes of e by: e.a 1 , · · · , e.a n . • The names and values of these attributes denoted by e.a i .name and e.a i .value respectively (i = 1, · · · , n). • e.value: the value of e, and e.value = NULL if e is a non-leaf node.
Example: Figure 3(a) shows an example of an XML instance, and the corresponding XML DOM tree for the this document is given in Figure 3

C. Converting XML Data to Relational Data
In this sub-section, we describe the relational database schemas that used to store XML documents. When trying to store XML document into a relational database tables one cannot use the DTD or XML Schema to generate a mapping, because if at all present with all documents, it might vary wildly between them. Therefore another approach is needed, something that maps the structure of XML itself. Note that to be useful for document storage, the document order needs to be preserved. Hence, we have mapped the XML DOM model onto the following relational database schema, Figure 4: The core of the mapping is the Element entity, that contains the following attributes: ElmId: A unique identifier for each element, DocId: The unique key of the associated document, ElmName: The name of this element, EmlValue: The text or data of this element (NULL for none), ParentID: The element which is parent to this element (NULL for the root element), OrderId: Element id of the next element in scope order (NULL for last element), and ElmDepth: The scope depth of this element. The Element entity is supplemented with two other entities. The first one is the Document entity, that contains the following attributes: DocId: A unique identifier for each document, and DocName: The name of this document. The second entity is the Attribute entity, that contains information about each attribute; such as, ElmId: The unique key of the associated element, AttName: The name of this attribute, and AttValue: The value of this attribute. In [5,6] we have introduced the "XR algorithm" that maps XML document to relational database tables. The XR algorithm takes the XML document file as input and stores its contents in a relational database tables. Figure 5 shows a database instance of the XR schema that explains how the XML document given in Figure 3 is mapped into the relational database schema given in Figure 4, by using the XR algorithm.

D. Creating XML Document From Relational Database
One of the most popular uses of XML is as a data storage facility. Because XML is based on a hierarchical data format, it's suitable to store almost any information, and it has the capability to mimic some of the capabilities found in relational database management systems (RDBMS). However, since XML is stored in a text format, data cannot be retrieved as quickly or stored as efficiently when compared to the binary formats used by modern RDBMS.
XML is often used to transfer data between disparate systems. A large number of systems today exchange data stored in XML even though they were never originally designed to do so. An example of such a systems are ecommerce business and M-learning. Sometimes, orders may be collected by one company and the merchandise is shipped by another company. In this type of business arrangement, the companies could use XML to exchange order information. Usually, the order data is stored in an underlying database, so the key for this type of transaction is to convert order data stored in a database into an XML document.

E. RX Algorithm for mapping relational tables to XML
document In [5,6] we have introduced the "RX algorithm" that used for extracting data from a database tables and insert it into DOM XML document. The pseudo-code for the RX algorithm is described as following: 1) Connects to the database and performs a Select query to get the relational data 2) Creating a new XML DOM document T, in which the data will transfer to it 3) The first element we create in the XML document is called the "root" element 4) For each row: add a new element to the XML document, using the table name, then insert it into the document as a child of the root element 5) Loop through each column in the current row, and insert the field name, and the corresponding value 6) Create a new element for the field and then insert it as a child to the current database row 7) Add the field value as a text node, then insert it as a child element to the current field node 8) Repeat from step 4: These loops do not terminate until they have processed every column of every row which has been retrieved from the database 9) Returns the completed XML document as a string 10) Insert the results into the "xmlfile.xml", and use it on the client browser 11) End.

A. Mobile Course Content
We categorize the Mobile course content that used for instructors and students interaction, into two groups: (1) The Mobile information content; and (2) The Mobile content: • The mobile information content: follows the traditional online course content, but course documents and materials will design by wireless infrastructure and deliver through wireless devices.
We identify the following wireless information contents: wireless syllabus, wireless schedule, wireless assignments, wireless labs, wireless course resources, and wireless tutorials. • The mobile interaction content: is highly depend on the type of the wireless device and micro browsers installed on these devices. We identify the following course interaction contents: wireless testing, wireless grades, useful links, SMS, chat, and wireless e-mail.
The information and the interaction contents both are generated dynamically from the course database. To assess student knowledge and learning outcomes, we provide various types of wireless quiz and test items such as: multiple-choice, true/false, and matching. The design of the wireless grades application is based on a grades database table and the application capabilities allow the instructor to specify the grading methods, procedures, and grading formulas, enter and update grades. The students have instant access to their grades through a WAP phone or a PDA. The wireless testing automatically saves the student test grades in the grades database table.
All items of the wireless information content are designed as tree data structures. The nodes of such tree structures contain separate sections from the information item. For example, as shown in Figure 6, the wireless syllabus is designed with such sections (nodes) as instructor information, course description, Lab. session information, textbook, course topics, and grades distribution.
The node course content is a parent node for syllabus, course lectures, course assignments, course tutorial, Lab assignments, test/quiz, SMS, and useful link nodes. The tree data structure has been chosen because it provides an easy mechanism for the implementation of the wireless information content and makes it possible to implement its delivery on wireless devices through menus, small size windows and basic navigation.

B. M-Learning Database Design
The database management system, store the user login records, course information contents, student profiles, instructor profiles, course quizzes (questions/answers), and the student grades. The database accessed and managed using Microsoft SQL Server database. Figure 7, shows the basic Entity Relationship Diagram, that used for creating the database schema and the database tables of MCMS. To prove the functionality of the Mobile Course Management System, we have implemented several wireless applications as components of the M-learning system. The system applications divided into two main parts: the student applications and the instructor applications.
1) The Student Applications: • Student Login: a student accesses the M-learning system through the URL. The system should ask the student to login in first. Once the student has a valid login name (student email) and a password, he/she can login to the system applications and choose a course from the list of courses in which the student enrolled. A student's unique key-login name is checked against a database of students' list. TAs) are granted access to the WCMS, they must successfully login to the system. The user's accounts are associated with different levels of privileges. Using a login name and a password is the most common authentication method. The login program supplies two input text boxes on the wireless device for user name and password. Once the user enters a user name and a password, the data are sent to the Web server to check against the course database. The authentication program on the Web server opens a database connection and retrieves the user record. If the user input data matches a database record, the user is granted to access the WCMS, and the system displays a list of instructor' courses that teaching in this semester. Otherwise, an "invalid login" message is displayed, and the login page is displayed again. • Mobile Course Management: The instructor (or TA) can login to a MCMS from any computer with Internet connection and work on the wireless course development, maintenance, updating, and monitoring. The instructor can create course information content (wireless course syllabus, lectures, assignments, tutorials, labs, self tests/quizzes, SMS, and useful links) using the interface based on PHP, ASP.NET and C#.NET forms. The teacher's responsibilities include upgrading the course content as required, monitoring the student progress, and creating and canceling student accounts. The MCMS system administrator duties are similar to the duties of a traditional Course Management System (CMS) administrator. The main system administrator's responsibilities comprise user management, course management on the Web server, and course database maintenance. The system administrator sets up a course "template" in accordance with a professor's request or deletes courses. The system administrator opens, closes teacher's accounts, and adds or deletes students from the course database.
VIII. CONCLUSION This paper proposes a full framework that serves two main purposes: • A mobile interface for Moodle, so that people can access their academic information (such as grades, homework, class notifications, etc.) from anywhere • Secondly it provides a basic interface to aid people with disabilities who find most standard websites cluttered and/or over-complicated.
Moodle itself is so customizable that almost all useful course management tools are provided. And because Mobile Moodle simply provides the mobile interface (and is not itself a wholly split program) any changes made to Moodle are mechanically converted for Mobile Moodle as well. The interface for Mobile Moodle is literally a Moodle interface, with the visuals stripped down and some of the formatting reworked to allow the pages to be displayed on almost all mobile devices with internet access.
Our platform serves as a more user-friendly interface for users with disabilities. Our system user gets exactly to the data they're looking for. Therefore, in joint with screen readers, brail encoders or other such devices, Mobile Moodle (which can be accessed on a computer as well) will save these users a significant amount of time. In addition, Mobile Moodle has an admin interface that allows course instructors and other authorized users to modify Moodle's appearance without ever looking at Moodle's code.