Abstract:
A method for servicing digital broadcasting, capable of defining a control message necessary for servicing digital broadcasting of a SD (Standard) level and a HD (High Definition) level through, a network of, for example, a x Digital Subscriber Line, by directly requesting, at a client, a digital broadcasting server for a session connection, and establishing a session by receiving a confirmation from the digital broadcasting server. Also, a channel change can be requested by directly requesting, at the client, the digital broadcasting server for a channel change, and changing a channel by receiving a confirmation from the digital broadcasting server. Other direct client-server requests and confirmations include a message for checking a status of the client and a session termination.

Description:
CLAIM OF PRIORITY  
         [0001]    This application makes reference to, and claims all benefits accruing under 35 U.S.C. §119 from an application for METHOD FOR CONTROLLING NETWORK DIGITAL BROADCASTING SERVICE earlier filed in the Korean Intellectual Property Office on Feb. 13, 2003 and thereby duly assigned Ser. No. 2003-9222.  
         BACKGROUND OF INVENTION  
         [0002]    1. Field of the Invention  
           [0003]    The present invention relates to a method and system for controlling a network digital broadcasting service.  
           [0004]    2. Description of Related Art  
           [0005]    As digital broadcasting is made more consistent, a number of broadcasting service models are being suggested. Among them, in a digital broadcasting service model through a network, a defined standard for providing broadcasting service between a broadcasting server and a subscriber terminal is required.  
           [0006]    In order for a subscriber apparatus (e.g. STB (Set Top Box)) to select one broadcasting channel from a multi-broadcasting server having a plurality of channels, a standard for defining a control message between a server and a subscriber apparatus, is required. For such a standard, a standard called “Part 6 of MPEG-2: Digital Storage Media-Command And Control” (referred to as DSM-CC hereinafter) defined under the “ISO/IEC 13818-6 International Standard” among standards generated by the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC), has been prepared. MPEG refers to the Motion Picture Experts Group.  
           [0007]    According to the DSM-CC standard, a session control and a channel change control are operated on different protocol stacks, respectively. Namely, a session control is based on TCP (Transmission Control Protocol)/UDP (User Datagram Protocol), and a channel change control is operated on the basis of AAL5 (ATM Adaptation Layer 5)/ATM (Asynchronous Transfer Mode).  
           [0008]    Also, a DSM-CC standard defines messages presuming a client to network (particularly, SRM: Session Resource Manager) to server as a service object. FIG. 1 is a structural view for one known embodiment of a digital information transmission system to which such DSM-CC standard is applied.  
           [0009]    Referring to FIG. 1, to realize, particularly, digital broadcasting service through a network (SRM)  12  in a digital information transmission system including a client  11 , a server  13 , and a network (SRM)  12 , the client  11 , for receiving a predetermined information or message using a digital storage media, uses the network (SRM)  12  to receive a message from the server  13 .  
           [0010]    Therefore, the network (SRM)  12  plays a role of connecting databetween the client  11  and the server  13 , and when wanting to receive a service, the client  11  requests the network  12  for a message, then the network (SRM)  12  recognizes such request, ordering desired information to the server  13 . The server  13  recognizes such order, transmitting desired information on the network (SRM)  12 , and the network (SRM)  12  checks transmitted information and then transmits data information and a message to the client  11 .  
           [0011]    [0011]FIG. 2 is a representative general timing diagram for digital broadcasting suggested by a DSM-CC standard of the related art. Referring to FIG. 2, for a control message for DSM-CC suggested by a DSM-CC standard of the related art, “Confirm method” is used.  
           [0012]    “Confirm method” used in a DSM-CC standard of the related art consists of a “Request” message, an “Indication” message, a “Response” message, and a “Confirm” message.  
           [0013]    Namely, a “Request” message is generated when the client  11  or the server  13  begin a message transmission and is transferred to the network (SRM)  12 . Also, the network (SRM)  12  delivers an “Indication” message which is information for a “Request” message to the server  13  or the client  11  with respect to such “Request” message. The sever  13  or the client  11  which receive an “Indication” message delivers a “Response” message to the network (SRM)  12  in response thereto. Then, the network (SRM)  12  responds with a final “Confirm” message, with respect to the client  11  or the server  13  which has initially delivered the “Request” message.  
           [0014]    A method by a DSM-CC standard of the related art for delivering digital broadcasting data, includes the steps of: making a session; changing broadcasting; checking a status of a server; terminating, at a client, broadcasting service; and terminating, at a server, broadcasting service.  
           [0015]    A method by a DSM-CC standard of the related art for delivering digital broadcasting data will be described in the following. First, a session is made between a client  11  and a server  13 , for discriminating, at a network (SRM)  12 , a subscriber apparatus (STB: Set Top Box) which is the client  11  in order to deliver such digital broadcasting data.  
           [0016]    A process for making such session will be described with reference to FIG. 2, in which: the client  11  delivers a “ClientSessionSetupRequest” message T 201  for establishing a session, to the network (SRM)  12 , and the network (SRM)  12  which has received such message transmits a “ServerSessionSetupIndication” message T 202  informing that there is a request for establishing a session from the client  11 , to the sever  13 .  
           [0017]    Also, the server  13  transmits a “ServerSessionSetupResponse” message T 203  to the network (SRM)  12 , and the network (SRM)  12  which has received such message transmits a “ClientSessionSetupConfirm” message T 204  to the client  11 .  
           [0018]    In the meantime, a process for releasing a session or a process for checking a status of a session is proceeded in the same manner.  
           [0019]    Namely, a process for checking a status of the client  11  will be described in the following, in which: the client  11  transmits a “ClientStatusRequest” message T 209  to the network (SRM)  12 , and the network (SRM)  12  which has received such message transmits a “ClientStatuslndication” message T 210  to the server  13 . Then, the server  13  transmits a “ClientStatusResponse” message T 211  to the network (SRM)  12 , and the network (SRM)  12  which has received such message transmits a “ClientStatusConfirm” message T 212  to the client  11 .  
           [0020]    Also, a process for checking the server  13  is performed in a following manner, in which: the server  13  transmits a “ServerStatusRequest” message T 213  to the network (SRM)  12 , and the network (SRM)  12  which has received such message transmits a “ServerStatuslndication” message T 214  to the client  11 , then, the client  11  transmits a “ServerStatusResponse” message T 215  to the network (SRM)  12  and the network (SRM)  12  which has received such message transmits a “ServerStatusConfirm” message T 216  to the server  13 .  
           [0021]    Also, a process for releasing, at the client  11 , a session is performed in a following manner, in which: the client  11  transmits a “ClientReleaseRequest” message T 217  to the network (SRM)  12  and the network (SRM)  12  which has received such message transmits a “ServerReleaseIndication” message T 218  to the server  13 , then the server  13  transmits a “ServerReleaseResponse” message T 219  to the network (SRM)  12  and the network (SRM)  12  which has received such message transmits a “ServerReleaseConform” message T 220  to the client  11 .  
           [0022]    In the meantime, a process for releasing, at the server  13 , a session is performed in a following manner, in which: the server  13  transmits a “ServerReleaseRequest” message T 221  to the network (SRM)  12  and the network (SRM)  12  which has received such message transmits a “ClientReleaseIndication” message T 222  to the client  11 , then the client  11  transmits a “ClientReleaseResponse” message T 223  to the network (SRM)  12  and the network which has received such message transmits a “ClientReleaseConform” message T 224  to the server  13 .  
           [0023]    In the meantime, as a channel changing process defined by a DSM-CC standard operates on AAL5/ATM, the client  11  directly transmits a “ProgramSelectRequest” message T 205  to the server  13  without passing session resource manager (SRM)  12 , and the server  13  which has received such message transmits a “ProgramSelectConfirm” message T 206  and the client  11  transmits a “ProgramSelectIndication” message T 207  to the server  13  without passing session resource manager (SRM)  12 , then the server  13  transmits a “ProgramSelectResponse” message T 208  to the client  11 , so that the channel changing process is terminated.  
           [0024]    A DSM-CC message used in the foregoing process consists of a message header that should be included in common for all the messages and a message payload for defining message data. Here, the message header includes a protocol discriminator and a message discriminator so that what kind of message has been transmitted, can be identified. Also, the message payload consists of peculiar data of each message. Among such peculiar data, detailed definitions are shown in Tables 1, 2, 3 with use of a “ClientSessionSetupRequest” message and a “ProgramSelectRequest” message for examples.  
           [0025]    Table 1 shows a header format of a DSM-CC message. Referring to Table 1, a DSM-CC message includes: a protocol discriminator consisting of 1 byte; a DSM-CC type consisting of 1 byte; a message ID (identification) consisting of 2 bytes; a transaction ID consisting of 4 bytes; a Reserved of 1 byte; an adaptation length of 1 byte; and a message length of 2 bytes.  
                           TABLE 1                                       A number           Contents   of bytes                           DsmccMessageHeader ( ) {               ProtocolDiscriminator   1           DsmccType   1           MessageID   2           TransactionID   4           Reserved   1           adaptationLength   1           messageLength   2           }                      
 
           [0026]    More specifically, the protocol discriminator is a field for indicating that a message is an MPEG-2 message.  
           [0027]    Also, the DSM-CC type is a field for indicating an MPEG-2 DSM-CC type, and for its possible type, four types exist such as UN (User-Network) configuration, UN primitive, UU (User to User) configuration, and UU primitive.  
           [0028]    The message ID is a field for determining a message type and the transaction ID is a field for session integrity or error processing. Also, the Reserved is a field for setting a value into “zero” for being reserved, and the adaptation length is a field for indicating a length of an adaptation part. The message length is a field for indicating a message length including the adaptation part.  
           [0029]    Table 2 shows a format of a “ClientSessionSetUpRequest/Confirm” message among  
                                 TABLE 2                           A number       Contents   of bytes                                ClientSessionSetupRequest ( ) {   ClientSessionSetupConfirm ( ){           dsmccMessageHeader ( )   dsmccMessageHeader ( )       SessionID   SessionID   10/10       Reserved   response    2/2       ClientID   ServerID   20/20       ServerID   Resources ( )   20/undefined       UserData   UserData       }   }                  
 
           [0030]    In the Table 2, the session ID is a discriminator for identifying one session and is a value consisting of a device discriminator of 6 bytes and a session number of 4 bytes, and the client ID and the server ID are values for identifying a client and a server in the network, respectively.  
           [0031]    The response has one code among codes such as “RspOK”, “RspNoSession”, “RspInvalidClient”, “RspInvalidServer”, “RspNoService”, “Reserved”. The client judges that a session is properly established only if a RspOK code is included in a response field and transmitted.  
           [0032]    The Resources () is a field for including detailed information of resources required for service, and it is not required right now, for it presently shows resource information for MPEG only, but it would be used in case that IP service is added afterwards.  
           [0033]    The UserData () is a part not defined in the standard and is depicted as “Out of Scope”.  
           [0034]    Table 3 shows a format of a “ProgramSelectRequest/Confirm” message among DSM-CC messages.  
                                 TABLE 3                           A number       Contents   of bytes                                ProgramSelectRequest ( ) {   ProgramSelectConfirm ( ) {           sessionId   sessionId   10       reserved   response   2       broadcastProgramId   broadcastProgramId   4       PrivateData ( )   PrivateData ( )       }   }                  
 
           [0035]    In the Table 3, the broadcastProgramild is a discriminator of a video program. Zero means a case that there is no program and a range for valid values is from 0x00000001 to 0x7FFFFFFF.  
           [0036]    The PrivateData () is a part not defined in the standard and is depicted as “Out of scope”.  
           [0037]    But, messages defined by such DSM-CC standard are base standard taking all cases for a variety of data format into account. Therefore, there are several problems in applying this standard as it is, to broadcasting service.  
           [0038]    First, messages taking general cases into account are defined, so that necessary messages are limited to a part depending on service characteristics.  
           [0039]    Secondly, a network which is a terminal apparatus, namely SRM is provided between a client and a server, so that a procedure for communication is divided into two steps. Upon change of broadcasting through TCP/IP (Transmission Control Protocol/Internet Protocol), changing time should be reduced as much as possible. In that regard, characteristics of dividing a procedure into two steps is a disturbing factor.  
         SUMMARY OF THE INVENTION  
         [0040]    To solve the above-indicated problems, it is an object of the present invention to provide a method for servicing digital broadcasting, capable of defining a control message necessary for servicing digital broadcasting of a SD (Standard) level and a HD (High Definition) level through, for example, an xDSL (x Digital Subscriber Line).  
           [0041]    Also, it is an object of the present invention to provide a method for controlling network digital broadcasting service, capable of realizing a session control and a channel change control on the same protocol stack by selecting only necessary control messages for servicing digital broadcasting, adding necessary part for service, making specialized protocol, and capable of reducing channel changing time by directly giving and taking messages without passing through a session resource manager (SRM).  
           [0042]    The foregoing and other objects and advantages are realized by providing a method for controlling network digital broadcasting service, including the steps of: directly requesting, at a client, a digital broadcasting server for a session connection, and establishing a session by receiving a confirmation from the digital broadcasting server; directly requesting, at the client, the digital broadcasting server for a program change, and changing a program by receiving a confirmation from the digital broadcasting server; receiving, at the client, a message for checking a status of the client from the digital broadcasting server, and directly delivering a confirmation message from the client to the digital broadcasting server; and directly requesting, at the client, the digital broadcasting server for a session termination and terminating a session by receiving a confirmation from the digital broadcasting server.  
           [0043]    The foregoing and other objects and advantages are additionally realized by providing a method for controlling network digital broadcasting service, including the steps of: directly requesting, at a client, a digital broadcasting server for a session connection, and establishing a session by receiving a confirmation from the digital broadcasting server; directly requesting, at the client, the digital broadcasting server for a program change, and changing a program by receiving a confirmation from the digital broadcasting server; receiving, at the client, a message for checking a status of the client from the digital broadcasting server, and directly delivering a confirmation message from the client to the digital broadcasting server; and directly requesting, at the digital broadcasting server, the client for a session termination and terminating a session by receiving a confirmation from the client.  
           [0044]    Foregoing and other objects and advantages are also realized by providing a method for controlling network digital broadcasting service, including the steps of: receiving, at a digital broadcasting server, a session setup request directly from a client, and establishing a session by directly delivering a session setup confirmation message to the client; receiving, at the digital broadcasting server, a program select request from the client, and changing a channel by directly delivering a program select confirmation message to the client; directly transmitting, at the digital broadcasting server, a server status request for checking a status of the client, to the client, and receiving a server status confirmation message from the client; and receiving, at the digital broadcasting server, a client release request for session termination from the client, and terminating a session by directly delivering a client release confirmation message to the client.  
           [0045]    Foregoing and other objects and advantages are further realized by providing a method for controlling network digital broadcasting service, including the steps of: receiving, at a digital broadcasting server, a session setup request directly from a client, and establishing a session by directly delivering a session setup confirmation message to the client; receiving, at the digital broadcasting server, a program select request from the client, and changing a channel by directly delivering a program select confirmation message to the client; directly transmitting, at the digital broadcasting server, a server status request for checking a status of the client, to the client, and receiving a server status confirmation message from the client; and receiving, at the client, a server release request for session termination from the digital broadcasting server, and terminating a session by directly delivering a server release confirmation message to the digital broadcasting server. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0046]    A more complete appreciation of the invention, and many of the attendant advantages thereof, will be readily apparent as the same becomes better understood by reference to the following detailed description when considered in conjunction with the accompanying drawings in which like reference symbols indicate the same or similar components, wherein:  
         [0047]    [0047]FIG. 1 is a structural view for a digital information transmission system to which a DSM-CC standard of the prior art is applied;  
         [0048]    [0048]FIG. 2 is a representative general timing diagram for digital broadcasting suggested by a DSM-CC standard of the related art; and  
         [0049]    [0049]FIG. 3 is a timing diagram for network digital broadcasting according to a preferred embodiment of the present invention. 
     
    
     DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS  
       [0050]    A preferred embodiment of the present invention will now be described with reference to the accompanying drawings. The matters defined in the description such as a detailed construction and elements are nothing but the ones provided to assist in a comprehensive understanding of the invention. Thus, it is apparent that the present invention can be carried out without those defined matters. Also, well-known functions or constructions are not described in detail since they would obscure the invention in unnecessary detail.  
         [0051]    In case of a VDSL (Very high-bit rate Digital Subscriber Line) presently under progress, channel data of all the channels could not be provided to the general household via a VDSL line like the case of FTA (Free to Air: ground wave) due to data transmission and reception speed restrictions (presently, maximum 52 Mbps for downward, 19.39 Mbps for broadcasting of a HD level). Therefore, a request for desired channel should be made through a network, and a subscriber apparatus should receive and show the relevant channel. By providing a message standard for realizing such broadcast changing procedure, it is possible to directly control broadcasting on a TCP/IP network and to watch a high quality channel.  
         [0052]    [0052]FIG. 3 is a timing diagram for a network digital broadcasting according to a preferred embodiment of the present invention. Referring to FIG. 3, according to the present invention, unlike the related art, an operation for the digital broadcasting is directly performed through “Request” and “Confirm” between a client  1   1  and a server  13  without going through “Indication” and “Response” steps.  
         [0053]    Like the method by DSM-CC of the related art for delivering digital broadcasting data, a process for delivering digital broadcasting data according to the present invention, includes the steps of: establishing a session; changing a channel (or program); checking a status of a client; terminating, at a client, broadcasting service; and terminating, at a server, broadcasting service.  
         [0054]    A method for delivering digital broadcasting data according to the present invention will be described with reference to an embodiment shown in FIG. 3. First, a process for establishing a session between a client  11  and a server  13  is performed without passing through a session resource manager (SRM). Namely, the client  11  directly transmits a “SessionSetupRequest” message T 301  to the server  13  and the server  13  directly transmits a “SessionSetupConfirm” message T 302  to the client  11  in response thereto, so that a session is established.  
         [0055]    Also, a channel changing process is performed on TCP/IP like the case of a session control, so that complexity of the message control of the related art could be reduced. Therefore, upon channel change, the client  11  transmits a “ProgramSelectRequest” message T 303  to the server  13  and the server  13  transmits a “ProgramSelectConfirm” message T 304  to the client  11 .  
         [0056]    In the meantime, the server  13  transmits a “ServerStatusRequest” message T 305  in order to regularly check whether the client  11  (subscriber apparatus (set top box)) operates constantly, and the client  11  responds to the server  13  by sending a “ServerStatusConfirm” message T 306  to the server  13 .  
         [0057]    Also, upon termination of the digital broadcasting service, a simple configuration of “Request-Confirm” is used. Namely, when requesting, at the client  11 , a broadcasting termination, the client  11  transmits a “ClientReleaseRequest” message T 307  to the server  13 , and the server  13  transmits a “ClientReleaseConfirm” message T 308  to the client, so that a session is terminated. On the contrary, when requesting, at the server  13 , a broadcasting termination, the server  13  transmits a “ServerReleaseRequest” message T 309  to the client  11  and the client  11  transmits a “ServerReleaseConfirm” message T 310 , so that a session is terminated.  
         [0058]    In the meantime, the present invention has newly constructed a payload of a DSM-CC standard message in order to service digital broadcasting . The process for performing service operation between a client  11  and a server  13  according to the present invention is different from the standard suggested by FIG. 2 in that service is directly delivered without passing through the session resource manager (SRM). Accordingly, a channel change message format and a status check message format have been changed appropriate for the service. Also, remarkably modified characteristics is that a session control and a channel change control are performed on the same protocol stack, so that all the messages include a message header. With such construction, a control becomes possible in a more simple process than the standard of the related art suggested in FIG. 2.  
         [0059]    For such message construction, refer to Table 4 through Table 7, below.  
         [0060]    Table 4 shows a format of a “SessionSetUpRequest/Confirm” message among digital broadcasting service messages through, for example, an xDSL according to the present invention.  
                                 TABLE 4                           A number       Contents   of bytes                                SessionSetupRequest ( ) {   SessionSetupConfirm ( ) {           dsmccMessageHeader ( )   dsmccMessageHeader ( )       SessionID   SessionID   10/10       Reserved   response   2/2       ClientID   ServerID   20/20       ServerID   }   20/        }                  
 
         [0061]    As shown in FIG. 4, a “ClientSessionSetUpRequest/Confirm” message defined by the present invention uses a message header of a DSM-CC standard for its message header. Also, a message delivering process that has passed through four steps of “Request”—“Indication”—“Response”—“Confirm” in the standard of the related art, is reduced and instead, a message delivering process is realized merely by two steps of “Request”—“Confirm”. In the meantime, UserData (), Resources () that have been used for the standard of the related art, are not used. For a client ID and a server ID, it is regulated that an address of OSI (Open Systems Interconnection) E.164 NSAP (Network Service Access Point), but a serial number given from an authentication organization is used.  
         [0062]    Table 5 shows a format of a “ProgramSelectRequest/Confirm” message among digital broadcasting service messages through, for example, an xDSL according to the present invention.  
                                 TABLE 5                           A number       Contents   of bytes                                ProgramSelectRequest ( ) {   ProgramSelectConfirm ( ) {           dsmccMessageHeader ( )   dsmccMessageHeader ( )       SessionID   SessionID   10/10       STB status   response   2/2       broadcast ProgramId   broadcast ProgramId   20/20       Client ID   Client ID   20/20       }   }                  
 
         [0063]    As broadcasting has been performed on AAL5/ATM in a DSM-CC standard of the related art, a message header has not been required. But, as a channel change message of the present invention is operated on TCP/IP like a case of a session connection message, a channel change message is constructed in the same format as the session connection message. Therefore, a message header and a client ID field are additionally provided.  
         [0064]    Also, a “STBStatus” field is added to a payload described in a DSM-CC standard of the related art so that a “Request” message is transmitted, whereby the general broadcasting and VOD (Video On Demand) could be discriminated. Also, a “Request” message is transmitted with a channel number to change put into its “broadcastprogramld” field.  
         [0065]    Table 6 shows a format of a “ReleaseRequest/Confirm” message among digital broadcasting service messages through, for example, an xDSL according to the present invention.  
                                 TABLE 6                           A number       Contents   of bytes                                ReleaseRequest ( ) {   ReleaseConfirm ( ) {           dsmccMessageHeader ( )   dsmccMessageHeader ( )       SessionID   SessionID   10/10       Reason   response   2/2       ClientID   ClientID ( )       }   }                  
 
         [0066]    The Client  11  could request a “ReleaseRequest” message in order to terminate a session, and the server  13  may also request a “ReleaseRequest” message in order to terminate a session by checking a status of the client  11 . The response message has one code among “RspOK”, “RspNosession”, “RspInvalidClient”, “RspInvalidServer”, “RspNoService”, “Reserved”, and the client  11  releases a session if a “RspOK” code is received.  
         [0067]    Table 7 shows a format of a “ServerStatusRequest/Confirm” message among digital broadcasting service messages through, for example, an xDSL according to the present invention.  
                                 TABLE 7                           A number       Contents   of bytes                                ServerStatusRequest ( ) {   SeverStatusConfirm ( ) {           dsmccMessageHeader ( )   dsmccMessageHeader ( )       Reason   Response   2/2       StatusType   StatusType   2/2       resourceNumber   resourceNumber   2/2       Reserved   resourceStatus   2/2       ClientID   ClientID   20/20       }   }                  
 
         [0068]    In case that a connection between the client  11  and the server  13  is abnormally terminated, the server  13  continues to broadcast, for a session is not normally terminated. In order to prevent such resource waste, the server  13  should regularly check a status of the client  11 . At the moment, a message transmitted to the client from the server  13  is a “ServerStatusRequest” message.  
         [0069]    Generally, the server  13  checks a status of the client  11  every thirty minutes, and if the client  13  does not transmit a “Confirm” message, the server  13  repeatedly transmits a “Request” message two times by short periods. If a “Confirm” message is not received even in this time, the server  13  terminates a session by transmitting a “Release request” message to the client  11 . Such check period is possibly changed on the program.  
         [0070]    A DSM-CC standard of the related art defines “reason”,“statusType”,“statusCount” fields, and the present invention adds “resourceNumber”,“resourceStatus”,“clientId” fields to that. For a “reason” field, one code among “RsnOk”, “RsnNormal”, “RsnError”, “Reserved” is possibly used. A “resourceNumber” among the added fields is a number of a resource (e.g. MPEG) whose status is wanted to be known. Also, a “resourceStatus” field is a field for informing a resource&#39;s status, showing a status that whether MPEG resource is being used.  
         [0071]    The method of the present invention as described above, could be realized in form of a program and stored at recording media such as CD-ROM (Compact Disk-Read Only Memory), RAM (Random Access Memory), a floppy disk, a hard disk, an optical magnetic disk, etc., in a form that could be read by a computer.  
         [0072]    As is apparent from the foregoing, the present invention accepts standard, extensionality, universality as a base standard with respect to DSM-CC of the related art, and is capable of performing swift message control.  
         [0073]    Also, the present invention unifies a basic protocol stack, so that realization of the present invention is easy.  
         [0074]    While the invention has been shown and described with reference to certain preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.