KR20000004802A - Remote lecture method at multimedia remote education system - Google Patents

Abstract

PURPOSE: A remote lecture method is provided to transmit lecture information and to support a lecture participation of a student. CONSTITUTION: The remote lecture method comprises the steps of: opening and maintaining a lecture by a lecture opener; requesting information for the opened lecture and multicasting progressed lecture information; and selecting a needed lecture among the multicasetted lecture information and requesting a lecture participation as an ID in order to take part in the lecture.

Description

Distance Teaching Method in Multimedia Distance Learning System

The present invention relates to a lectic lecture method that transmits lecture information and supports student participation in a lecture in order to enable a student to participate in a lecture at the request of a student in a multimedia distance education system using a multimedia.

In the past, one specific host (server) dedicated to the processing of lecture information was used for the transmission and participation. Then, the lecture information was periodically transmitted.

However, the conventional method using the server has a fatal problem in that when the server fails, the transfer of lecture information and the participation of lecture participants cannot be handled.

In addition, it was necessary to connect with the client in order to notify when the lecture information changed.

However, this conventional method causes a problem of information inconsistency among the participants and increases the load on the network.

The present invention devised to solve the above problems, in the distance education system using a multimedia provides a lecture method for transmitting the lecture information and support the student's participation in the lecture so that the student can participate in the lecture at the request of the student Its purpose is to.

In other words, the present invention is a computer-based integrated multimedia distance learning system developed on the basis of a multimedia application development platform (DooRae), such as lecture information transmission and support for lecture participation to support the participation of students at the request of participants. The aim is to provide a distance learning method that supports participation in the community.

1 is an exemplary configuration diagram of a multimedia distance education system to which the present invention is applied.

2 is an exemplary configuration diagram of a process of transmitting and processing information on a distance education class for explaining the concept of the present invention.

3 is a flow diagram of one embodiment of a remote lecture method according to the present invention.

4 is a detailed flowchart of one embodiment of a lecture participation process according to the present invention;

* Explanation of symbols for the main parts of the drawings

21: User 1 22: User 2

23: User 3

In order to achieve the above object, the present invention provides a remote lecture method applied to a multimedia distance learning system, the first step of the lecture creator to create and maintain a lecture; A second step of multicasting ongoing lecture information when a participant requests information on the opened lecture; And a third step in which the participant arbitrarily selects a desired lecture from among the multicasted lecture information and requests to participate in the lecture by using the identifier for the selected lecture.

In addition, the method of the present invention is characterized in that it further comprises a fourth step of updating the course information according to the end of the course, if the lecturer is notified of the end of the lecture.

The above objects, features and advantages will become more apparent from the following detailed description taken in conjunction with the accompanying drawings. Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

First, the concept of the present invention will be described in brief. The method of the present invention uses Internet Protocol Multicast and is used in an integrated multimedia distance learning system based on a self-developed multimedia application development platform.

In addition, the present invention provides a local program for supporting lecture information transmission and lecture participation using the Internet Protocol Multicast (IP Multicast) protocol, and when there is a new generation of a lecture or a request for updating the lecture information from a client. Only when sent.

1 is an exemplary configuration diagram of a multimedia distance learning system to which the present invention is applied, and shows a configuration of a daemon used in an integrated multimedia distance education system, and includes a module dedicated to storing and managing lecture information. It has a part in charge of the interface.

Common elements required for session management include creating and terminating sessions, managing access to participants, and maintaining participant information after allowing access. However, the above factors alone make it difficult to proceed with a session using multimedia resource objects supporting a system of a multimedia application development platform. Therefore, the access control between the participants for the control of the media resources for the user's service request processing and the right to speak is required. And, it must be able to support and manage sessions that can meet the various needs of users. In general, the user's needs associated with a session are:

Concurrent participation in multiple sessions or simultaneous progression of multiple sessions

Free movement between multiple sessions in progress

-Allow Join On Demand or Leave On Demand when you want

-Automatic generation of scheduled sessions or session participation without participant involvement

Session participant selection of the creator of the session. That is, the ability to restrict access to sessions of disallowed participants

Thus, there is a need to further extend the management elements for sessions that support the above five user needs, which are not provided in existing and standardized studies.

In order to create a session, an invitation process and a network resource acquisition process are essential.

The creation of a session begins by asking a user to create a session manager through the user interface, which is referred to as an initiator (this is not fixed, just a term for identification). In this case, the application must specify the requirements for the session through the configuration and various options for the resources to be used in the session.

If the request for the resource to be used by the user is successful, the network resource is acquired. After acquiring the network resources, network resources are allocated to the media service provider through the session manager generated by the daemon.

An invitation process is conducted to connect with a remote session participant, providing two methods: invite all to anyone using the Multimedia Application Development Platform (Dure) daemon and invite a designated user to a limited number of users. do. However, by providing two ways to respond to remote participants in both methods, we can have four types of invitation.

The response method is participant-oriented by displaying a method of creating a generator-centered response that establishes a session without asking the remote participant established by the session creator whether or not to participate and displaying a dialog box asking the remote participant information about the session creator and whether or not to participate in the session. Provide a response method. The former has the advantage of providing convenience to people who are not good at using computers or operating multimedia application development platform, and creating sessions quickly when session participants are decided. Participation in a session can be offensive. The latter case has the advantage of respecting the intention of the remote participant, while the creator does not know when to finish the invitation and may not be able to participate in the session despite having responded to the invitation. When the invitation process is completed, information about the participant is transmitted to all the participants by the session creator. At this time, the session is terminated by generating the application and media resource providers to be used for the session.

The following is the classification by invitation method and response method.

-All invited / responded by the creator

-All invited / responded by participants

-Invitee by designator / Response by constructor

-Invited designator / Response by participants

Meanwhile, referring to the resource allocation process, resources used in the session include audio, video, application sharing, whiteboard, and electronic blackboard, which are resources of the session itself, and multicast group addresses (Multicast) as network resources. Group Address and Network Port.

First, resource acquisition of the session itself is achieved by the session manager requesting a resource from a media resource service provider. Hooking for audio, video and application sharing, which is only one resource in a computer system, is already assigned by the media resource service provider. Each instance is created according to a resource request to provide a service for a session.

In the case of a video service provider and a whiteboard using a software codec having no physical resource limitation, a process of generating a new processor becomes a resource acquisition process.

The protocol for acquiring network resources can be divided into two types. One is obtained by the Network Resource Manager, which is responsible for assigning the multicast group address and the network communication port, and the other is by negotiation between daemons. In the former case, since network resource managers are allocated to network resources through a single window, it is easy to solve the problem of resource conflicts. However, there is a disadvantage that a session can be created only when the network resource manager is running at all times. . Currently, the network resource manager implemented in the multimedia application development platform (due) system allows only one per multicast group address. Therefore, when using the same group address, there is a security problem that can expose session information to an unwanted party. . On the other hand, in the latter case, the problem of network resources is resolved by negotiation between daemons, and the burden of session formation is small, but as the number of sessions increases, the negotiation process on network resources can be lengthened. Problems may appear.

Session Termination is handled in four ways: Session Initiator Oriented, Participant Oriented, Session Monitor Oriented, and System Manager Oriented. At the end of the session, all media resource instances and network resources allocated and used by the session are returned and returned to the state they were in before the session was created.

If the session is session creator centric, the session ends with the session manager's session manager termination. At this time, the session manager delivers control information instructing the end of the session to the remote site, and the participant manager notifies the application of the end of the session and ends the session. This is a commonly used mode.

In participant-oriented sessions, the session creator is just a virtual administrator. The session is maintained as the original session creator transfers control of the session to another participant manager during the withdrawal process. However, if all participants leave, the session ends automatically.

Session monitor-driven session termination is provided through Session Monitor, which can monitor overall network traffic and has participants' survival checks and session monitoring capabilities. If a certain level of response to the session monitor's survival check does not come from the participant session manager, the session manager is considered to be difficult to proceed anymore and the other participant managers are notified of the end of the session manager.

System administrator-driven session termination is accomplished by forcibly requesting session termination through the session monitor. This function is provided to terminate the session by the system administrator for the stable progress of an abnormal session, an impact on another session, or an important session.

Next, referring to Multiple Session Management, multiple sessions refer to simultaneous progression of sessions using the same or different application protocols on the same host. In other words, multiple sessions allow a user to participate in two or more sessions at the same time to act as participants or creators of sessions. In the session management protocol of the present invention, one host can allow simultaneous progression of applications based on a multimedia application development platform (tele) such as distance learning and teleconferencing. There are two types of multiple sessions: multiple sessions using different application protocols and multiple sessions using the same application protocol. In other words, the former is a multi-session using different resources and protocols, the latter is a case where a multi-session is implemented using the same protocol, although the configuration for the resource may be different.

Simultaneous progress of multiple sessions can be allowed by classifying sessions by the session identifier (ID) used by each session and by avoiding data collision using different communication channels. The session identifier (ID) and the communication channel are assigned by the network resource manager during the creation of the session.

In order to allow multiple sessions, the physical system must support the use of multiple resources. However, most computer systems often have only one resource allowed throughout the system. Therefore, a system resource management method is required to support multiple sessions.

In most computer systems, there is only one audio resource, so for the purpose of supporting multiple sessions, one audio service provider provides resources through mediation, multiplexing, or mixing. As each session is created, the service provider creates a created service provider instance, which supports multiple sessions using resources of a parent service provider.

The video service provider is similar to audio. In case of video service provider by software, there is no restriction of computer system, so it provides multiple video windows according to session manager's request.However, when using hardware codec, only one codec is used due to limitation of computer system. do. Therefore, there is only one video window that can be provided by a video service provider. However, by changing the image provided at the request of the session manager, the user can simultaneously participate in multiple sessions. To provide.

Only one whiteboard journal playback hook (WH_JOURNALPLAYBACK Hook) and whiteboard journal record hook (WH_JOURNALRECORD Hook) used by the application sharing service provider are provided throughout the computer system. Therefore, in order to implement multiple instances, the application sharing service provider captures all system messages and then duplicates the message to the appropriate application sharing service provider instance.

Software providers, such as whiteboards and electronic blackboards, have no system limitations. In such cases, multiple instances can be implemented simply by running independent processors.

Now, when looking at Multiple Instance Management, providing one resource instance in one session will limit the flexibility of the user's use of resources, limiting sessions using interactive multimedia collaboration. Will be added. Therefore, even in one session, it is necessary to provide a plurality of resource instances in order to provide a service for a user's additional resource allocation request.

In fact, existing teleconferencing, distance education research and programs have limited only one instance of a resource. As a result, only sequential sharing was the solution. However, this behavior is different from the human way of thinking. In addition, by reducing the chance of continuous thinking and access to the document to be shared each time to change the shared content to provide a user inconvenience.

The session manager creates a corresponding media instance manager for the resource instance request of the user, allows the media service provider to create a media service instance, and manages the created media service instance. Therefore, the session manager manages the media instance manager and thereby controls the media service instance.

After the use of the media service instance is terminated, the media instance manager is notified to handle the media instance manager destruction. The session manager on the creator side informs the media service provider that handles the creation and termination of the media instance that the media service instance has been terminated and notifies the remote session manager after confirmation. The session manager of the participant will perform the media instance destruction.

In this structure, since the media service instance and the media instance manager have a 1: 1 relationship, there is no limit to the number of media instances that can be supported for a session. However, if you actually allow too many media service instances, it will only cause confusion for the user, so you will have to limit the maximum number of instances you can create.

Next, if you look at Nested Session Management (Nested Session Management), it can be said that the most natural form of the session is the nested session (Nested Session). Nested sessions refer to the presence of multiple child sessions under one parent session.

It is difficult to model real-world group conferences into distributed, interactive multimedia conferences. Among them, modeling nested sessions is the biggest obstacle due to the complexity of session control and resource issues of media instances.

In the present invention, three basic principles are applied to design and implement nested sessions.

First, by default, newly created child sessions inherit the settings of the parent session. However, the configuration of the nested session can be changed by the configuration through the constructor of the parent session. The nested session's moderator specified by the moderator of the parent session inherits the rights of the parent's creator. The nested session's moderators inherit from the parent session as follows:

-Right to arbitrate the voice when the voice mode is the chairman mode of arbitration

-Right to terminate nested sessions

Second, all participants between nested sessions should have the same access rights to all resources supporting multimedia sessions. That is, one nested session cannot monopolize multimedia session resources.

Third, one participant cannot participate in two nested sessions at the same time. That is, one participant is allowed to participate in only one nested session.

In order to model nested sessions, it is necessary first to allow multiple instances in one session and to separate the nested sessions. By default, each nested session has one media service instance. That is, a media instance manager is created for each nested session.

The media service instance created by the nested session manager allows only one media instance manager by default, unless specified by the creator of the session.

Separation between nested sessions is distinguished only by nested session identifiers (IDs) assigned by the parent session manager. The data channel of the nested session uses the same channel as the parent, and distinguishes the destination of the data by transmitting the identifier (ID) of the nested session in the header of each packet.

Participation in nested sessions is limited to the authority of the session creator. The session creator performs all tasks such as creating, terminating, modifying information, and changing participants through the nested session controller interface. The session creator can define the nested session identifier (ID), the nested session name, the participant to participate, the voiced method of the nested session, and the resources that can be used to create the nested session.

Participants in the nested session can move to the session creator's arbitration after requesting the session chairman if they wish to move to another nested session. Participants in a nested session can only access data and session information from the nested session, and no access to other nested sessions. Participants who do not belong to a nested session will join the session in the same manner as the existing session, and cannot access or access other nested sessions.

Now, referring to Session Maintenance and Recovery, a media service instance of a session may be abnormally terminated while the session is in progress. In this case, the session may be interrupted, but as long as the system allows, it is necessary to reactivate the media service instance to protect the user.

In order to proceed with the restoration of the session, a method for error detection is needed first. In most computer systems, there is only one method for error detection. First, one method is to periodically check the processor database that keeps the state of executed processors. However, this has the disadvantage that the database must be examined up to a processor independent of the state of the session using the multimedia application development platform. Therefore, in a system using a multimedia application development platform (Dure), an error detector is notified of information about a processor created by a daemon or a session manager, and the error detector periodically polls only the processor directly associated with the session to perform error detection. do.

The daemon provides information about the session manager and the media service provider created by the daemon, and the session manager provides the error detector with information about the application and the instance of the media service provider needed to proceed with the session.

If there is no response from the sensing object for a certain time or a certain number of times, the error detector considers the abnormal situation and notifies the processor that created the sensing object.

Respond to notifications of abnormal conditions. There is a case where restoration is impossible due to hardware problems. First, recovery can be done by simple redo and retransmission of information, such as whiteboards and application shares, and recovery can only be done by freezing hardware resources such as audio / video. You may not be able to. The session restoration procedure is performed when it is possible and when it is impossible.

Participation in Session Restoration Procedure Reboot the system in the session information logging process and save the minimum information necessary for session restoration as a file. The information stored here is as follows.

-Session Information: Session Name, Session Identifier (ID), Session Manager Communication Channel

-Participant information: information about the session creator, information about the participants

-Application Information: Application name, communication channel used by the application, whether reserved communication channel is used or not

Media service provider information: communication channel to be used by the instance

FIG. 2 is an exemplary configuration diagram of a process of transmitting and processing lecture information for distance education for explaining the concept of the present invention. It shows control and data flow.

First, the lecture creator (user 1) 21 generates the lecture (24). If the user 2 (22) or the user 3 (23) requests the information on the opened lecture (25), the lecture creator 21 or the manager multicasts the ongoing lecture information (26). Then, user 2 22 or user 3 23 selects and participates in the desired lecture (27).

FIG. 3 is a flowchart illustrating an embodiment of a remote lecture method according to the present invention, which shows an outlined course information transmission request and a processing procedure for transmission, and shows an interaction relationship between each component module.

Referring to FIG. 3, a process of generating and transmitting lecture information and deleting lecture information at the end of a lecture is as follows.

First, when an application is executed, the executed application requests the daemon for information about a lecture already established (31).

The daemon that is requested for the lecture information is a remote daemon requesting information about the lecture opened by the lecture creator (32). In this case, only the lecture creator can transmit the lecture information to a remote place. This is to reduce network traffic. If everyone can send it, this is a problem because n * (n-1) / 2 traffic is generated for N people. However, when the above algorithm of the present invention is applied, it is treated as n traffic occurrences.

The remote daemon receiving the lecture information transmits the lecture information to the requested daemon (33).

The daemon receiving the lecture information from the remote daemon stores all participant information, and transmits the lecture information to the application whenever one response is sent from the remote daemon (34). If none of the remote daemons sends the class information (if no class is open), the application waits for a certain period of time and notifies the application that there is no class information.

On the other hand, if the remote daemon of the lecture creator terminates the lecture (35) and notifies the participant manager that the lecture has ended (36), the participant manager informs his daemon of the completion of the lecture (37) and each daemon at the end of the lecture. Update the lecture information according to (38).

4 is a detailed flowchart of an embodiment of a lecture participation process according to the present invention.

That is, FIG. 4 is a flowchart illustrating an example of a process in which a student participates in a distance education class opened by a lecturer, such as a teacher, and the like, using a lecture information received in FIG. The process of supporting this is shown.

First, the application selects one of the lecture information received from the daemon and informs the daemon of the lecture's identifier (ID) (41).

The daemon receiving the lecture identifier creates a participant manager (session manager) using the lecture identifier information (42).

The created session manager presents an invitation dialog box to get the participants' information (43).

When the participant requests to participate in the lecture, the participant manager transmits a packet requesting permission to participate in the lecture to the remote session manager (the lecture creator), and also transmits the participant information of the participant together (44).

The lecture creator transmits the participant information to the remote location through the received information, and transmits the information to the participant manager (45). Up to this point, all lecture and participant information to be transmitted by the session manager is distributed.

The session manager (participant manager) notifies the application that he has participated in the lecture (46).

A server is created (47), and an instance is created (48) to create the server instance required in the lesson (49).

The created server instance or server informs the session manager of its creation (50).

The present invention described above is not limited to the above-described embodiments and the accompanying drawings, and various substitutions, modifications, and changes can be made in the art without departing from the technical spirit of the present invention. It will be apparent to those of ordinary knowledge.

The present invention as described above, the computer-based multimedia distance learning system to overcome the obstacles caused by using the existing server, there is an effect that can provide the convenience of participation to the student as a participant.

In addition, students who are participants can maintain the independence between participants by requesting lecture information from the lecture creator and using the information to ask for lecture participation regardless of the status of other students.

And as a whole, there is an effect that can improve the stability of the entire system.

Claims (6)

In the distance teaching method applied to the multimedia distance education system, A first step in which the lecture creator creates and maintains the lecture; A second step of multicasting ongoing lecture information when a participant requests information on the opened lecture; And A third step in which the participant arbitrarily selects a desired lecture from among the multicasted lecture information and requests to participate in the lecture by using the identifier of the selected lecture. Remote lecture method made, including. The method of claim 1, A fourth step of updating lecture information according to the completion of the lecture when notified of the completion of the lecture by the lecture creator. Remote lecture method made up more. The method of claim 2, The fourth step, A fifth step of terminating a lecture by a remote daemon of the lecture creator; A sixth step of the remote daemon notifying the participant manager of the completion of the lecture; A seventh step in which the participant manager notifies the daemon of the completion of the lecture; And Eighth step for each daemon to update the course information at the end of the course Remote lecture method made, including. The method according to any one of claims 1 to 3, The multicasting process of the lecture information, Remote lecture method, characterized in that only the lecture creator is possible. The method according to any one of claims 1 to 3, The second step, A ninth step of, if the application is executed, the executed application requesting a daemon for information about the generated lecture; A tenth step of requesting the lecture information, the daemon requesting information on the lecture generated by the lecture creator as a daemon at a remote location; Step 11, the remote daemon receiving the requested lecture information transmits the lecture information to the requested daemon; And The daemon receiving the lecture information from the remote daemon stores the participant information, and sends the lecture information to the application whenever a response is sent from the remote daemon. Remote lecture method made, including. The method according to any one of claims 1 to 3, The third step, An ninth step of the application selecting one of the lecture information received from the daemon and transmitting the lecture identifier to the daemon; A tenth step in which the daemon receiving the lecture identifier generates a participant manager (session manager) using the lecture identifier information, the generated session manager displaying an invitation dialog box for obtaining the participant information; When the participant requests to participate in the lecture, the participant manager sends a packet requesting permission to participate in the lecture and participant information to a remote session manager (the lecturer); A twelfth step of the lecture creator sending participant information to the remote site and the participant manager through the received information; A thirteenth step of notifying the application that the session manager (participant manager) has participated in the lecture; And Step 14 of informing the session manager of the creation after creating the server instance required in the lesson Remote lecture method made, including.