Title of Invention

A SERVER UNIT AND A CLIENT UNIT IN A COMMUNICATION NETWORK

Abstract

The real-time performance in communications networks is improved, especially between a large number of participants, by means of a server unit comprising receiving means for receiving information from at least a client unit, said information comprising at least part of the state information about a distributed interactive application, said server unit comprising: state information storing means for storing application state information received from at least one of said client unit, transmission means for forwarding the state information received from said client to at least one other node in the network, and for transmitting at least part of the information stored in said state information storing means to said at least one client. In this way the whole state of the application can be kept in one or more units in the network, which removes the need for each client to store the entire state, thereby reducing memory and banwidth requirements for each client.

Full Text

FORM 2 THE PATENTS ACT 1970 [39 OF 1970] COMPLETE SPECIFICATION [See Section 10] "METHOD AND APPARATUS IN A COMMUNICATION NETWORK" TELEFONAKTIEBOLAGET LM ERICSSON [PUBL], a Swedish company, of S-126 25 Stockholm, Sweden, The following specification particularly describes the nature of the invention and the manner in which it is to be performed:- WQ-G&68864- -PCT/SE00/0Q93T 2 Method and Apparatus in a Communication Network Technical Field The present invention relates to communications networks and in particular to the 5 real-time communication between several users of an application in such a network. Description of Related Art Multi-user communications applications are currently being developed, for example for multi-user games. Such games may be played by a number of users connected to 10 the same LAN or even to different pans of larger networks, such as the Internet. For such applications, three main synchronization models are used: client-server synchronization, peer-to-peer synchronization or broadcast synchronization. Some multi-user games on die Internet today involve up to 100 000 players, of which several thousand may be playing at the same time. All synchronization methods used 15 today cause rather long delays. Therefore, the multi-user games played over the Internet today are games in which the speed is not critical. For example, fast action games, such as car racing games or battle games, in which the user must react to what is happening within fractions of a second cannot be played with acceptable quality using any of the standard synchronization methods. 20 Dial-in networks typically use client-server synchronization. In this case, a server receives data from all players. It has to find out what information each player needs and send it. The central server is an obvious bottleneck in the system. Central client-server games can support 2 - 250 players. The higher number refers to servers 25 where the update rate is as low as 2 Hz. The central server adds latency both because of the increased transport distance and the processing and scheduling delay in the server. Consider e.g. a situation where the clients are on the U.S. West coast while the server is on the U.S. East coast. About 80 ms of transport latency and at least several 10 ms of processing latency are caused by the client-server mode of 30 operation. -WO 00/68864- - PCT/SE0Q&Q932- Therefore, client-server synchronization is not feasible for real-time applications with large numbers of players in which the delay is critical. Peer-to-peer synchronization means that all clients send application data directly to 5 all other clients. This model is frequently used for games that are played over the public Internet. Game developers provide a free application lobby server where players meet for setting up games and for joining ongoing games. Once a game has started it is played in the peer-to-peer mode without drawing any resources from the game developer's site. 10 Peer-to-peer synchronization has obvious scaleability problems since the network load is proportional to the square of the number of players; the client access bandwidth and CPU power requirement are proportional to the number of players. The payload in each packet is 10-40 bytes, which means that the protocol overhead 15 usually is more than 50%. Small game packets give a large protocol overhead. With header compression methods, however, this overhead can be reduced significantly. Peer-to-peer games over the Internet suffer from unpredictable delays and frequent collapses because of loss of synchronization. 20 It follows that peer-to-peer synchronization, too, is best adapted to small networks, with communication over relatively short distances and between a limited number of users. Broadcast synchronization can be used by a limited number of players on a Local 25 Area Network (LAN) but is not suitable for larger networks. Because of the restrictions posed i.a. by the synchronization methods, multi- participant communications with good real-time characteristics is not possible with current technology 30 With multicast the information that has to be transmitted in the network can be sig- nificantly reduced, in that information only has to be transmitted once to each mul- ticast server, instead of once to each user. Each multicast server then copies the information and transmits it to the users connected to it. A selection of the information each user needs to receive may be made. This may reduce traffic both between servers and between each server and its users. Such a solution for use in gaming is 5 disclosed in US 5 841 980, In the system disclosed in US 5 841 980 each user only has the information related to the part of the game which is relevant to the user in the current situation, e.g. information about the geographical area he is in. If the circumstances change, for ex- 10 ample, if the user moves to another room, information that is important in the new circumstances will not be available to the user. Object of the Invention It is an object of the present invention to improve the real-time performance in 15 communications networks, especially for collaborative communication between a large number of participants. Summary of the Invention This object is achieved according to the invention by a server unit for use in a 20 communications network, said server unit comprising receiving means for receiving information from at least a first client unit, said information comprising at least part of the state information about a distributed interactive application, said server unit being characterized in that it comprises - state information storing means for storing application state information com- 25 prised in the information received through the receiving means from at least one of said first and second client units, - first transmission means for forwarding the state information received from said at least first client unit to at least one other node in the network, - second transmission means for transmitting at least pan of the information stored 30 in said state information storing means to said at least one client unit. WO 00/68864 5 FCT/SE 00/00937 This enables keeping the whole state of the application in one or more units in the network, which removes die need for each client to store the entire state, thereby reducing the need for memory capacity in each client and also the bandwidth needed for communication with each client. If each part of the state of the applica- 5 tion is stored in more than one network node or client, a back-up facility is achieved. The object is also achieved according to the invention by a client unit for use in a terminal in a communications network, comprising an application software for a 10 distributed interactive application client unit being characterized in that it comprises - at least one input means for reading an input from said terminal, said input con stituting at least application state information for the distributed interactive appli cation - transmission means for transmitting application state information to an applica- 15 tion access server - receiving means for receiving at least application state information for the distributed interactive application from said application access server - means for displaying said state information. 20 The method and apparatus according to the invention are particularly useful for distributed interactive applications, especially involving real-time communication. Preferably, the receiving means of said server means is adapted to - receive subscription information from at least said first client, said subscription 25 information identifying objects of the distributed interactive application about which said first client wishes receive information, - transmit information to said at least one client unit in dependence of the sub scription information received from that client unit, - said server unit further comprising at least one client subscription list for storing 30 said subscription information. Accordingly, said client unit further comprises means for setting subscription information for specifying at least one object of the distributed interactive application from which available information should be received and means for transmitting said subscription information to said application access server. 5 This reduces the amount of information to be transmitted to each user, thereby reducing the transmission delay and also helping each user analyze the information, since only the most imponant information for a particular user is shown to that user. Each client is able to decide for itself what is important. 10 In a preferred embodiment, the receiving means is adapted to receive urgency information relating to said first client from at least a second client. The urgency information may be transmitted to the first client, or application state information regarding said second client may be forwarded to at least said first client in depend- 15 ence of said urgency information. The urgency information may also be used to indicate that certain application state information should not be forwarded to said first client. The urgency information may be used to change a client subscription. In said preferred embodiment the client unit further comprises means for setting ur- 20 gency data for specifying at least one other client that should receive state information from the client as soon as possible. Advantageously, the transmission means of the client unit for transmitting application state information is adapted to arrange information in object information pack- 25 ets, each packet relating to one object constituting part of the application, before transmitting the packets to the server unit, and said receiving means is adapted to extract information from packets received from the server unit. The application access server system is independent of the application and can 30 therefore support a wide range of different applications. WO-60/68864 I PCT/SE00/00932 - Application access server units working together could communicate over a network, which preferably offers reserved or managed transmission capacity. The aggregated bandwidth requirement of an application can be estimated by the network management system and sufficient network resources can be allocated to the re- 5 served network that is connecting the application access server units. New applications are allowed only if resources are available. The network management also controls the resending and duplication policy of the application access server units. Multicasting and resource reservation protocols can be used on "the aggregated streams between the application access server units. The advantage of this system is 10 that resource reservation on the player level is not necessary. Application clients can usually handle occasional lost packets if the overall statistical performance is good. Using the application access server according to the invention means that a game client never will lose synchronization permanently since the application access server units always maintain the game state. 15 Brief Description of the Drawings The apparatus and method according to the invention will be described in more detail in the following, with reference to the appended drawings, in which: Figure 1 illustrates an embodiment of a network according to the invention; 20 Figure 2 illustrates an application access server according to a first embodiment of the invention; Figure 3 shows an embodiment of an application state record according to the invention; Figure 4 shows an application client according to an embodiment of the invention; 25 Figure 5 illustrates the communication stacks used according to an embodiment the invention; Figure 6 shows a second embodiment of the application access server according to the invention; Figure 7 shows an application router used in the second embodiment of the applica- 30 don access server; 00/08864 l *PCT/SE00/00932- Figure 8 is a schematic representation of a hierarchical structure of application access servers used in an embodiment of the invention. Detailed Description of Embodiments Figure 1 shows an embodiment of a communications network according to the invention. According to the invention, the network comprises at least one application access server. In Figure 1, a first 1, a second 3 and a third 5 application access server are shown, connected to each other through a network 7, for example, a reserved telecommunications network. It may also be any other type of network, however, networks in which it is not possible to reserve network resources, such as the Internet, may provide a lower quality if heavily loaded. A number of clients 11, 12, 13, 14, 15 are also connected to the network 7. A client can connect to the appropriate application access server 1, 3 or 5 in any way known in the art, as will be discussed in more detail below. Clients can communicate with each other through the application access servers for the purpose of running a distributed interactive application, in which a large member of participants simultaneously affect and contribute to the state of the application, for example a real-time multi-user game. Between each client and the application access server to which it is connected there will usually be a low capacity connection, such as a modem connection. Between two application access servers, on the other hand, high and variable network capacities will be available. The application access servers according to the invention are therefore adapted to handle the information about the state of the application in such a way as to reduce the amount of information transmitted to each client, by transmitting to each client only the information that is most relevant to this client. Between the application access servers, the transmission capacity will not normally be a problem and therefore more information can be transmitted between application access servers. W0 00/65864 9 PCT/SE00/00932 One or more application lobby servers 21, of a kind known per se, may also be present in the network. These servers typically comprise functions that allow the clients to register for a particular type of service, handle billing functions, etc. 5 According to the invention, the software required for the application is found in the client 11, 12, 13, 14, 15. To use the communication functions according to the invention, therefore, the user must make sure he has the application software needed. The application software may be retrieved in any way known in the art, for example, downloaded from the Internet or installed from CD-ROM. If required for the 10 application he must also register with the application lobby server. Typically, the application lobby server 21 will provide an address, usually an IP address and port number of one or more application access servers 1, 3, 5, but this address may also be obtained in any other way. 15 The user connects to an application access server in the way common in the art, normally by entering the IP address of the application access server or a pool of application access servers. Several algorithms exist for selecting the appropriate one of a number of nodes in the network identified by the same address. The application access server receives information from the user and starts transmitting information 20 to the user, as will be described in more detail in the following. Instead of the client logging in to the application access server, the application lobby server can also transmit client network addresses to the application access servers. The application is assumed to consist of a set of objects, which are controlled by the 25 participants. An object is an entity in the application that is controlled by a human participant or that is generated in a client and cannot be regenerated locally in each application client, e.g. controlled by a random generator or other unpredictable computing process. Application objects can be things that the participants will intuitively recognize as objects, or game figures, but they can also be background data 30 structures such as environment variables that are controlled by players. An application object is controlled by one or several players. Each object typically has a set of WO00/68864 10 PCT/SE00/00932 properties and attributes that may be changed while the application is running. In a game these properties may be a character's strength and other capabilities, or the maximum speed of a car, and the attributes may be, for example, items collected by the character. 5 The information received from the user will normally comprise three different types of information, in addition to the signalling overhead: state information, subscription information, control data and urgency information. The state information is information about the object or objects that are controlled by the user, which should 10 . be distributed to other users of the application. The subscription information lists the client's priorities regarding different application objects provided by the application access servers. For example, information regarding a certain group of objects should be received at once it becomes available, or as often as possible, whereas information from another group of objects is not that urgent. Several priority levels 15 may be set, for example, in the form of acceptable delays or precedence in case of lack of bandwidth. The urgency information generated by a client may be used to override or change the subscriptions of another client so that the other client will receive information about objects that are not included in its subscription, or to make sure that the client does not receive certain information. All three types of in- 20 formation will be discussed in more detail below. As an example, the application of a real-time game being played by a large number of users, will be described. Such games are played today with a limited number of players, located fairly near each other, for example in a local area network (LAN). 25 Played over a wide area network, such a game may in the future involve several thousands of players, typically distributed over a large game field, or virtual geographical area. With prior art technology this is not possible with an acceptable quality, as discussed above. 30 Each player is immediately affected only by the things that happen near him in the virtual game area. The farther away another player is. the less important changes to WO 00/68864 11 'FCT/SE00/00932 this player will be. For example, a player may be involved in a fight with a first hostile player, a friendly player may be coming to rescue and a second hostile player may be trying to stop the friendly player. At the same time, other players will be doing.things that may become interesting at a later time, but for the time being, 5 the player's main concern is to survive the fight. Therefore, the movements of the first hostile player must be displayed immediately. The movements of the friendly player and the second hostile player should also be given a high priority, while the things happening farther away should be given a low priority. " l0 In the example discussed above, obviously, the configuration of the players will change so that at another time information from other players will have the highest priority, usually the players who are located near the user at any given time. The application access server handles communication with application clients. It re- 15 ceives information about the actions of the client that affect the application state and other information. It also transmits application state information from other participants to the participants according to their subscriptions. Each application client sets subscriptions regarding which application information to receive and transmits information about these subscriptions to the application access server. The application 20 access server stores and updates a record of the subscriptions of the clients that are served by the application access server. The subscriptions of each client are used to determine which data is to be sent to this client. A client might also set subscriptions for another client. In one mode of operation, a master client might for example set the subscriptions of all other clients. The application access server to which a client is connected is that client's local application access server, and the client is referred to as a local client of that application access server. 30 The application access server also keeps a client authority list. Each client has the right to change the state of one or more game objects. The client authority list has WO 00/68864 12 -PCT/SEOO/00932 one entry for each client where the identifiers of the objects that are controlled by the client are stored. The application access server checks the authority each time it receives object state information from a client. The game state will be updated only if an identifier found in the information packet matches one of the numbers in the 5 entry for the client in the authority list, otherwise the information is ignored. Object state information arriving from other application access server units is not verified ;ince the sending application access server has already checked for authority. Each application access server also communicates with other application access 10 server units, sending application state information and, optionally, aggregated subscriptions to them and receiving the same type of information from them. Usually, the information to be transmitted to the other application access servers is packaged according to an appropriate protocol and transmitted without being prioritized or sorted in any way. It would of course be possible to select the information to be 15 transmitted to each application access server in dependence of the users' subscriptions of its local clients. Aggregated subscriptions are the sum of all application object requests from clients belonging to a given application access server. For example, the application access server may use multicasting to other application access server units. This ensures that each application access server unit receives all 20 needed updates and that the game state is distributed efficiently over the application access server units. Urgency data is set by a client if the data is important to another client but this other client is not aware of this and therefore cannot set his own subscriptions. The ur- 25 gency is therefore defined by the sending client and may be different for different receiving clients. The application access server alerts the receiving client if urgent data is waiting. The urgency information may also be used to prohibit the forwarding of certain information to one or more clients. 30 Each application access server also stores and updates a complete or partial copy of the application state. Between them, the application access server units that are allo- WO 00/68864 PCT/SEOO/00932- cated to a communication session must store the complete application state. In the simplest case, every application access server stores the complete application state, but it is also possible to split the information between the application access servers, with or without overlapping information. Such solutions require special software to . handle the distribution of the appropriate data to each application access server. The application access server communicates with the application lobby server for setting up the application, adding and removing participants while the application is running and handling errors and network failures. Figure 2 shows an application access server 50 according to an embodiment of the invention, with its functional entities. This application access server could be implemented in hardware or in software. In connection with Figure 2, only a general description is given. Appropriate formats and protocols will be discussed later. The application access server receives data from each client in the network, and from other units, such as other application access servers, through input buffers 51. There is one input buffer for each client, remote application access server and application lobby server, although in Figure 2, for clarity, only one input buffer is shown. The actions of each local participant are sent as payload in application object packets that arrive in the input buffer of the application access server associated with this client. These application object packets update application objects that are controlled by the participant. The application object packets are written into the application state record using-a set of insertion rules. The data received from the clients may comprise three types of data: data about the state of the application (state data), data about the subscriptions of the client (priority data) and other control information, such as requests for time reference, status of other clients and other information from the system. The state data is passed WO 00/68804 14 PCT/SE00/00932 through an application object packet pipeline 53, to an application state record 55. The application state record 55 keeps all the state data for all the relevant objects, as will be described in more detail in the following. The application state record also keeps the urgency data as described above. – 5- Groups of clients may be defined, said group for example comprising the participants in a working group or, in the case of a game, in die same team. In this case, subscriptions and/or urgency data may also be specified for groups of users, not only for individual users. 10 Control data, especially data that does not have to be handled in real time, such as information on added or removed application objects, is passed from the input buffer 51 to the application access server control unit 57. In a hardware implementation the control unit 57 may be a microprocessor. Control data handled by the . control unit could be related, for example, to the creation and destruction of players 15 and objects, and to groups of players and objects. Subscriptions are passed through an application priority control protocol message pipeline 59 to a Client Priority List (CPL) 61 containing the subscriptions of each client that is supported by die application access server. The subscriptions can be 20 updated by the clients and by the application access server control unit. The control unit could decide, for example, to update the subscriptions of a client in response to an urgency message received from another client. Several different prioritization strategies can be employed by die application clients 25 using the application access server system. A simple method is that application clients send an enumerated list of objects to the CPL 61. In this case objects not on the list could be updated, for example, in a round-robin mode when all the objects on the list have been updated. If all objects in the list have been updated the remaining objects could be updated, for example in 30 a round robin mode. The subscriptions of a particular client comprises a list of all objects for which a subscription has been set by this client. In addition the list stored WO 00/68864 15 PCT/SE00/00932 in the application access server preferably comprises a flag for each object indicating if new information for the object has been received. The flag is used to determine whether or not information about a certain object needs to be sent to the client. When the information has been sent to the client, the flag is reset. When a new up- 5 date for an object is received by the application access server, the flag is set again. The client subscriptions could also be defined with a time interval associated to each object. The client would then send a series of requests, for example of the format: 10

Documents:

in-pct-2001-01372-mum-cancelled pages(09-05-2005).pdf

in-pct-2001-01372-mum-claims(granted)-(09-05-2005).doc

in-pct-2001-01372-mum-claims(granted)-(09-05-2005).pdf

in-pct-2001-01372-mum-correspondence(ipo)-(13-05-2005).pdf

in-pct-2001-01372-mum-correspondence1(21-02-2005).pdf

in-pct-2001-01372-mum-correspondence2(25-07-2007).pdf

in-pct-2001-01372-mum-drawing-(09-05-2005).pdf

in-pct-2001-01372-mum-form 13(05-12-2001).pdf

in-pct-2001-01372-mum-form 13(17-07-2006).pdf

in-pct-2001-01372-mum-form 19(27-04-2004).pdf

in-pct-2001-01372-mum-form 1a(21-02-2005).pdf

in-pct-2001-01372-mum-form 2(granted)-(09-05-2005).doc

in-pct-2001-01372-mum-form 2(granted)-(09-05-2005).pdf

in-pct-2001-01372-mum-form 26(19-05-2006).pdf

in-pct-2001-01372-mum-form 3(07-11-2001).pdf

in-pct-2001-01372-mum-form 3(20-07-2004).pdf

in-pct-2001-01372-mum-form 5(07-11-2000).pdf

in-pct-2001-01372-mum-power of authority(09-01-2001).pdf

in-pct-2001-01372-mum-power of authority(21-02-2005).pdf