Lecture Notes in Computer Science- P112 pps

Architecture for m-learning system As illustrated in figure 1, four elements will be included in our system: registrar, proxy, m-learning server and user entity.. Any user in this domai

3 Architecture Design for Mobile Learning

The m-learning architecture based on SIP should support the requirements of tradi-tional e-learning processes, which include registration, message communica-tion,courseware subscription, and other methods that will fully engage the students in the learning process through an interactive, dynamic environment involving the stu-dent, on-line materials and teacher As discussed in section 2.1, the new architecture should also support the unique requirements of m-learning, which include enough flexibility and mobility At the same time, it should have high multimedia data ex-change capacity[11] The architecture proposed in this paper is illustrated in figure 1

IP-based network

Smartphone

User Entities

m-learning server

registrar/proxy Database

Fig 1 Architecture for m-learning system

As illustrated in figure 1, four elements will be included in our system: registrar, proxy, m-learning server and user entity A registrar is a server that accepts learners and educators’ registration and provides m-learning server with proper information A proxy server primarily plays the role of routing It receives SIP message and decides the next hop M-learning server is used to provide users with functions such as courseware subscription and play, presence subscription, and so on The user entity is

a logical entity that can act as both UAC(user agent client) and UAS(user agent server) Installed at user’s terminal devices, the user entity is implemented as a client software for accessing m-learning services

With the increasing use of SIP in various fields, there are already many developed SIP software and applications We will reuse these resources to implement our m-learning system For example, SER(SIP Express Router) is a free SIP server licensed under the open-source GNU license We will use SER as registrar and proxy in our

system The development of m-learning server and user entity will be based on oSIP, eXosip and oRTP, which are open source SIP software

4 System Implementation and Message Flow

In this section, we will discuss the detailed implementation of the m-learning system using SIP The flow charts of main processes are given, together with primary SIP messages

4.1 Register Process

The registrar is an administrator for a specified SIP domain Any user in this domain who wishes to get an m-learning service, should register to the registrar with its AOR (address of record) and contact address The procedure of register includes challenge and response steps based on HTTP digest [12] Once the user is authenticated and authorized, the contact address will be used by proxy for routing future SIP requests The register process and message example are shown later in figure 6, together with re-register process Note that we only include the main part of SIP message in all examples

4.2 Message Route Process

The proxy is a center node between all SIP users and m-learning server On receiving a request, the proxy will decide which destination it should be sent to Commonly, it is completed mainly by analyzing the request URI in SIP request For example, if the URI of

a request is something like sip:alice@nbut.cn, which is a user URI in this domain, the re-quest will be directed to the contact address (got from registrar) which the user Alice regis-tered with However, if the URI is something like sip:courseware@nbut.cn, this request will be directed to m-learning server In the m-learning system, only two functions are related with proxy: instant message and common SIP call Considering for system sim-plicity and cost, the proxy and registrar are implemented in one software in our system (SER is used as both registrar and proxy) and located in one single PC server The mes-sage sending process is shown in figure 2

Fig 2 Process of message sending

In this process, Alice sends a SIP MESSAGE request with a request URI of sip:bob@nbut.cn to proxy which will route it to Bob When the user entity of Bob receives the request, it responds Alice with a SIP response message of 200 OK and prompts Bob with the message body, which is “Hello.” The detailed SIP message is

as follows:

MESSAGE sip:bob@nbut.cn SIP/2.0

From:

<sip:alice@nbut.cn>;tag=dvR+vtR+rrK2a59Rc5ayhgsQfo

To: <sip:bob@nbut.cn>

Call-ID: nJ3dNL3du.MqeF.jgFc-139qC4@192.168.0.100

Content-Type: text/plain

Hello

SIP/2.0 200 OK

From:

<sip:alice@nbut.cn>;tag=dvR+vtR+rrK2a59Rc5ayhgsQfo

To: <sip:bob@nbut.cn>;tag=4c78dd21

Call-ID: nJ3dNL3du.MqeF.jgFc-139qC4@192.168.0.100

4.3 The Implementation of M-Learning Server

The m-learning server is an application server providing m-learning functions It im-plements three basic functions, including accepting subscription for user presence information, accepting subscription for courseware list, and providing real time play-ing of a specific courseware The first two processes are illustrated in figure 3 and figure 4 The process of courseware real time playing is shown later in figure 6 The process in figure 3 shows that when the user entity of Alice starts, it will sub-scribe all users’ presence info from m-learning server The server will then return the presence information, such as “Tom is online” and “Marry is offline”, by sending a SIP NOTIFY request message Once a new user, say, Bob, registers to the registrar, the registrar will inform m-learning server by some method (commonly not SIP) The m-learning server will then generate a new NOTIFY message with Bob’s online in-formation in its body and send it to Alice The process in figure 4 is very similar with that in figure 3

4.4 The Implementation of User Entity

The user entity is implemented as a client software at user’s terminal devices User will

be required to configure the address of registrar and proxy when the software is installed

at the first time Once the user entity begins to run, it will register to the registrar and subscribe for other users’ presence information and available courseware If the

subscriptions are accepted, the user entity will maintain a user list and courseware list in the software user interface and display them to the user When another user is registered

or deregistered to the registrar, the m-learning server will send a NOTIFY message to the user entity, which will refresh its user list (someone online or offline) If someone in the user list is online, the user could send him an instant message or make a call The courseware subscription and notifying process is in most part like the pro-cess of pres-ence subscription and notifying, except that the courseware information is maintained

by a system administrator, not by a registrar When a courseware is available, it can be played in user’s terminal devices

Fig 3 Process of subscribe presence Fig 4 Process of subscribe courseware

Fig 5 Process of register and re-register

The user entity is also responsible for implementing mobility Once the user entity detects that the terminal device has changed its network connection, it will re-register

to the registrar with the new network address of the terminal device as the new con-tact address, ensuring that the future requests of the user entity will be routed to the new address If the user entity is already in a SIP session, say, having a call with someone or playing a courseware, it will begin an update flow to refresh the contact address and the media address in SDP, so that the media stream will be continued with only a short interrupt The register and reregister flow is illustrated in figure 5 The session update flow is shown in figure 6

In this flow, the user entity of Alice registers its contact address of 192.168.0.100

to the registrar On receiving the SIP REGISTER message, the registrar will authenti-cate the message originator by responding the user entity with a SIP response message

of 401 Unauthorized The user entity gets the challenge information in this response message and calculates a challenge response based on challenge, user name, password and other information A new REGISTER message containing this response will be sent again to the registrar The registrar will check this challenge response If the re-sponse matches the one in registrar, which means the authentication is succeeded, the registrar will return a response message of 200 OK to Alice If anytime the network connection changes, which results in IP address changing to 192.168.1.200, the user entity of Alice will re-register to registrar with a new contact address of 192.168.1.200 and an old challenge response The registrar will save the new address

in its database and response Alice with 200 OK The SIP message details are as follows:

REGISTER sip:nbut.cn SIP/2.0

From:

<sip:alice@nbut.com>;tag=nVfdNPfdu7qq_tnj*t4-U39aC8

To: <sip:alice@nbut.com>

Call-ID: fverVterCnrc.PmB9P5OeciLSb@192.168.0.100

Contact: <sip:alice@192.168.0.100:7060>

SIP/2.0 401 Unauthorized

From:

<sip:alice@nbut.cn>;tag=nVfdNPfdu7qq_tnj*t4-U39aC8

To: <sip:alice@nbut.cn>;tag=7849

Call-ID: fverVterCnrc.PmB9P5OeciLSb@192.168.0.100

WWW-Authenticate: DIGEST realm="nbut.cn",

algo-rithm=MD5,nonce="dd2de673348f1d19337082e347115bf1"

REGISTER sip:nbut.cn SIP/2.0

From:

<sip:alice@nbut.cn>;tag=nVfdNPfdu7qq_tnj*t4-U39aC8