Arrangement for improving availability of services in a communication system

<u style="single">Field of invention</u>The present invention relates to devices that improve the availability of services in communication systems, especially telecommunications systems, which include distributed hardware and software components in which one or more interact with each other. Provide services to users of. More specifically, the present invention relates to user mobility support in distributed systems. More specifically, the present invention relates to an improved use of agent technology.<u style="single">Current technology</u>An open distributed system is a category of distributed system, consisting of components that can be obtained from many different sources, and these act as a single distributed system to each other. An open distributed system provides an application interface to a distributed system, and this application can be run on any suitable local operating system. The TINA architecture (Telecommunications Information Network Architecture) is a specialization of open distributed systems for telecommunications applications, and the present invention is primarily related to such TINA architectures. It was developed. The TINA-C architecture addresses the issue of personal (user) mobility, but does not use a large number of agents for each user. In addition, this architecture allows, for example, additional constellations that allow one user to use different terminals of the same or different capabilities, and allows several users to use the same terminal. It does not deal with permits. Other than TINA, there is no architecture that addresses user mobility on distributed systems. As a result, there are increasing demands for user mobility, especially in relation to distributed systems, and so far no suitable solution has been proposed for distributed systems.<u style="single">Purpose of the invention</u>An object of the present invention is to propose an implementation of improved availability of services in communication systems, especially support for user mobility in distributed systems. Another object of the present invention is to provide a device that allows a user to move while still allowing access to an application / service. Yet another object of the present invention is to provide improved availability, which allows one user to use several terminals of the same or different capabilities, thereby allowing several users to use the same terminal. Is to do. Yet another object of the present invention is to provide a device that allows the separation and protection of objects belonging to different users but running on the same terminal. A further object of the present invention is to propose to each mobile user an improved use of a large number of agents.<u style="single">Abstract of the invention</u>The above objectives are achieved in the type of device described in the preamble, which is primarily characterized by introducing user mobility support into the device, which enables application availability, including personal mobility. And. More specifically, the above objectives are achieved by introducing the user mobility support for distributed systems. Further features and advantages of the present invention will become apparent from the following description with accompanying drawings and the appended claims.<u style="single">[Simple explanation of drawings]</u>FIG. 1 is a schematic diagram illustrating user mobility defined for interactions. FIG. 2 is a schematic diagram showing an embodiment of the present invention, particularly the introduction of a user agent required for user mobility support. FIG. 3 is a schematic diagram illustrating an operation started by a mobile user. Figure 4 is a schematic diagram illustrating the behavior initiated by an object in the telecom system domain. FIG. 5 is a schematic diagram illustrating one particular embodiment of the invention, including dedicated object user registration means for storing registration data. FIG. 6 is a schematic diagram illustrating an interaction with a default user domain. FIG. 7 is a schematic diagram illustrating the functionality of the user interface object. FIG. 8 is a schematic diagram illustrating one embodiment of local registration. FIG. 9 is a schematic diagram illustrating a procedure for local registration. FIG. 10 is a schematic diagram illustrating one embodiment for remote registration. FIG. 11 is a schematic diagram illustrating a procedure for remote registration. FIG. 12 is a schematic diagram illustrating one embodiment of local registration cancellation. FIG. 13 is a schematic diagram illustrating one embodiment for a procedure for local registration. FIG. 14 is a schematic diagram illustrating remote registration cancellation. FIG. 15 is a schematic diagram illustrating a procedure for remote deregistration. FIG. 16 is a schematic diagram illustrating an example of registration of a large number of terminals. FIG. 17 is a schematic diagram illustrating one embodiment of a user registration object having an object registration ability. FIG. 18 is a schematic diagram illustrating one embodiment of one registration of a user object.<u style="single">Detailed description of embodiments</u><u style="single">Definition of user mobility</u>Here, Telecom System_NDomain, Terminal_mDomain and User_aConsider an example consisting of domains. User_aThe domain is User_aIt consists of an object and a voluntary calculated object called CO1. Where the object CO1 is Terminal_mIt can be physically resident inside or not. If the user is also a terminal or hardware device, CO1 is Terminal_mIt can be resident on the user itself rather than on the domain. Providing user mobility allows the entire user domain, including CO1, to move and change devices, and still the Telecom System._NTo be able to interact with the object CO2 that resides in the domain. Interaction means both behavior and stream flow. This is shown in Figure 1.<u style="single">Using the agent</u>Next, we introduce the agents needed to enable the interaction between each domain. User_aPD_UA to represent_a(ProviderDomain_User_Agent_aThe agent called) is called Telecom System._NIntroduce to domain. The agent undertakes security features such as identification, authentication, and encryption, which are also responsible for supporting user mobility. TDm-UA_a(TerminalDomain_User_Agent_a) Another agent called Terminal_mBy introducing it in the domain, User_aAnd also Terminal_mUndertake the security function of. This User_aIs another terminal, for example Terminal_nIf you are also using TDn_UA_aAlso Terminal_nDefine for that user on the domain. Further assume that every terminal must have an owner and that it is reasonable to define this owner as the default user for that terminal. Legal and up-and-coming terminals will always have one default user. This default user is permanently registered with the terminal. By defining a default user for a terminal, we can implement access control procedures that can also limit the use of that terminal. Of course, the default user can also register with another terminal, but the former registration is always valid, and we will have the case of multiple terminal registration. Therefore, Terminal_mAgent TD_UA representing the default user deployed in the domain_mThere is. Correspondingly, Telecom System_NAgent PD_UA in domain_mIntroduce. In addition, we have Terminal_mTelecom System in the domain_NSPAN representing the domain and Telecom System_NTerminal in the domain_mIt has a TAm representing, a TAP representing a terminal access point (port), and a NAP-like object representing a network access point. This is shown in Figure 2.<u style="single">Enable operation between mobile users and telecommunications systems</u>The operation is User_aBy or by Telecom System_NWe consider the two cases separately, as they can be initiated by any of the objects in the domain.<u style="single">Actions initiated by the mobile user</u>Now suppose CO1 wants to call the action OpY () on object CO2. This call is not made directly. First of all, the action Call (CO2.OpY ()) is the object TD_UA_aIssue to. This is CO2 and TD_UA_aIndicates that there must be a relationship with. The definition of this association is described below. Next, TD_UA_aIs its peer-object PD_UA_aAction Call (O2.OpY ()). TD_UA_aAll that is required for this to issue this action request is the object PD_UA_aIt is an identifier of. TD_UA_aAnd PD_UA_aBoth represent the same user and only one unique PD_UA_aTD_UA because there is only_aFor PD_UA_aFinding the identifier of is not a problem. In fact, both of these two objects carry the user identification they represent. PD_UA_aAction Call (O2.OpY ()) for SPAN behavior Call (PD_UA)_aConvert to .Call (CO2.OpY ())). SPAN is its peer object TA_mAction request for Call (PD_UA)_aIssue .Call (CO2.OpY ())). This request is the action Call (TA) for TAP_mCall (PD_UA)_aConvert to .Call (CO2.OpY ())). The TAP then sends this action to the NAP to which it is currently connected. NAP then calls the action request (PD_UA)_a.Call (CO2.OpY ())) to TA_mEmit to. TA_mNext, PD_UA_aCall (CO2.OpY ()). This PD_UA_aNow calls the action OpY () of the object CO2. This ends with the transmission of the action OpY (). Invoking actions by objects in the user domain is seamlessly supported. The only information required from the user domain is that CO2 resides (or is located within the telecom system domain) on a fixed kTN. No other additional information is required. This is shown in Figure 3.<u style="single">Behavior initiated by an object in the telecom system domain</u>See Figure 4. Now suppose that the object CO2 in the telecom system domain wants to call the behavior OpX () of CO1. This behavior is PD_UA_aOperation Converts to Call (CO1.OpX ()). To enable this conversion, CO1 is User_aInformation that belongs to the domain and does not belong to any other user domain must be available within the telecom system domain. TD_UA_aThen the object TD_UA_aAction Call (CO1.OpX ()). The first request for this is TD_UA_aIs to find the identifier of. For the time being, we assume that such information is available. We will soon return to how to find this. The operation request is then TA_mAction for Call (TD_UA)_aConvert to .Call (CO1.OpX ())). To do this, PD_UA_aIs TA_mIdentifier or terminal such as User_aIs located in Terminal_mMust have an identification of. The procedure for obtaining this required information to reach the mobile user is commonly known as location tracking, which often complements the procedure for registering and deregistrating locations. .. For the time being, PD_UA_aSomehow get enough information and the correct Terminal_agent, eg TA_mSuppose you call. From this step to step 6, all actions are related to the handling of terminal mobility. TA_mCall (SPAN.Call (TD_UA)) to forward this call to its peer-to-peer object SPAN._aThis is done by issuing .Call (CO1.OpX ())) to NAP. The NAP forwards this call to the corresponding TAP. TAP then SPAN Call (TD_UA)_aCall .Call (CO1.OpX ())). SPAN is TD_UA_aCall (CO1.OpX ()). Finally, TD_UA_aCalls the action OpX () of object CO1. This ends with the transmission of the action initiated by the object in the telecom system domain. We have found that the condition for the success of these procedures is the availability of information about the current terminal that the user is using or has access to. Formally, the success of the action initiated by an object residing on the telecom system domain is PD_UA._aDepends on the definition of the association between and TA. User_aPD_UA when is moving_aThe association between and TA is changing correlatively and is therefore sometimes undefinable. The action required to determine this relevance is part of a procedure commonly referred to as user registration and deregistration.<u style="single">Registering and unregistering user locations</u>User location registration and deregistration is a procedure that determines the association between PD_UA and TA. There are many ways to do this, which are described in the sections below.<u style="single">On-the-Fly method</u>The most linear method is the "on-the-Fly" method. This method is also called "lazy" because nothing should be done until it is needed, for example until a request is made. User is the object CO2 that resides in the telecom system domain._aWhen you want to call the behavior of object CO1 that belongs to the domain, make a request PD_UA_aEmit to an object. PD_UA_aThe object broadcasts to all TAs, asking them to search for mobile users. These TAs correspond to one of them, the SPA, with the corresponding TD_UA._aYou can ask to search for. If none of the SPAs succeed, User_aCannot be reached. Nothing else can be done. One SPA is its move User_aIf successful in finding, this responds to the corresponding TA, and this TA again PD_UA_aNotify to. At this time, PD_UA_aCan send an action call to the TA in question, and this TA sends it to the corresponding SPA. SPA does this behavior TD_UA_aSend to an object, and this object sends it to object CO1. The interaction is now enabled. This method is satisfactory for small and "lowly geographically dispersed" systems, that is, systems with a small number of terminals and a small number of users. It can be time consuming for larger or geographically dispersed systems. It can take some time to find a user or to know that it is not possible to find that user. This method also requires considerable activity in the telecom system domain. If there are n terminals and m users in the system, in the worst case, an m × n search procedure may be started at the same time to find all m users. This method is used on the Internet when search engines are used to identify the location of another web page or information location.<u style="single">Predetermined method of association between PD_UA and TA</u>There is another method based on the pre-determination of the association between PD_UA and TA. PD_UA knows in advance whether the mobile user has contact with any TA and whether it is associated with that particular TA instance. In other words, the PD_UA object has the ability to remember the association between PD_UA and TA. A simple implementation is to use a TA identifier, which is a type of "distribution transparent" pointer to a TA. This method saves a considerable amount of time at runtime when an action request is issued. This TA identifier does not necessarily have to be incorporated in PD_UA, but can be realized as User_Registration that provides a registration information service for a separate calculation object, for example, PD_UA object. This User_Registration object can contain several TA identifiers, as it is possible to allow one user to use several terminals at the same time. The second piece of information needed is the corresponding TD_UA identifier. This information can be derived from the user's identification and the terminal's identification, but it is more convenient to store it. Shorter response times are obtained as less processing is required at run time. A User_Registration object containing information about TD_UA and TA is shown in Figure 5. Here, the question is how PD_UA can get information about TD_UA and TA, and when the update should be done to ensure consistency with the user's actual movement.<u style="single">Default registration</u>As mentioned earlier, any terminal is associated with the default user who owns this terminal. In this case, the association between PD_UA and TA is always defined. We can call this the default registration. Again, the object CO2 is User_aLet us consider an example when we want to call the behavior OpX of the object CO1 that belongs to the domain. Here, User_aIs Terminal_mSuppose you are the default user of. When the operation request Call (CO1.OpX ()) is received, PD_UA_aIs User_Registration_aBehavior Call Get_Registration (). User_Registration_aChecks its TD_UA and TA tables, and the default TD_UA and TA identifiers, ie TD_UA_aAnd TA_mAnd PD_UA_aReturn to. PD_UA_aIs TA_mAction on object Call (TD_UA)_aProceed to call .Call (CO1.OpX ())). This procedure continues as described above until full operation OpX is achieved. This is shown in Figure 6.<u style="single">Local registration</u>Local registration is User_aIs User_mTerminal belonging to_mIf you want to use. In practice, local registration belongs to an access session, and the purpose of this access session is to enable users to access the service. Some requirements must be imposed on the terminal before it can continue. To allow several users to access the telecom system domain using the same terminal, this terminal is currently used in some more local "intelligence", i.e., a fixed network. It must have more processing and functional capabilities than the terminal of. We are Terminal_mIntroduce an object called UI (User_Interface) in the domain. This object is responsible for overseeing and controlling the interaction between the terminal and each user. The UI has a function of switching between different users when several users share the same terminal. At the time of request, the UI can also serve new incoming users by creating a new TD_UA object. In Figure 7, we show an example with three users. User_{b b}And User_cIs already Terminal_mIt is registered in. At the time of request, the UI switches between these two users, i.e. input / output channels TD_UA_{b b}Or TD_UA_cCan be connected to. This switch request can be fulfilled in a variety of different ways, such as entering the command New-User (), pressing a key, or clicking the mouse over an icon. User_aWhen comes and wants to use the terminal, this user issues a request New-User. The UI can create new and "temporary" TD_UA objects. Temporary means that this TD_UA is not yet associated with any user, or more specifically, any PD_UA known and recognizable for this telecom system domain. There is. This association will only occur after a successful execution of local registration. The UI also connects input / output channels to this TD_UA. Now User_aWill be able to interact with the temporary TD_UA. Next, let us return to our example. User_aMakes the user himself Terminal_mSuppose you want to register with. After calling the action New-User () and getting the temporary TD_UA assigned to him, User_aEnters his user identifier (or name) in its temporary TD_UA (see Figure 8). From the user identifier, the temporary TD_UA behaves LocalRegister () as its PD_UA_aCorresponding PD_UA knowing that it must be called against_aDerivation of the computational interface identifier (CII) for. Therefore, this temporary TD_UA starts the transmission of the operation LocalRegister () by calling the operation Call (PD_UAa.LocalRegister ()) to the SPAN. This call is communicated through TAP, NAP, and TA_mTo reach. TA_mNext, PD_UA_aCall the LocalRegister () action for. PD_UA_aInitiates security procedures. As shown in Figure 9, we now assume that this security procedure is successful. PD_UA_aIs User_Reg_aAction against Set-Registration (TD_UA, TA_m), Which is TD_UA and TA_mSave the identifier of. PD_UA_aReturns the status OK to TD_UA. TD_UA is PD_UA_aSave the identifier of, and User_aBecome a permanent agent associated with. TD_UA is Terminal_mUser for_aStay alive until the final deregistration of.<u style="single">Remote registration</u>Remote registration is User_aBut remote Terminal where he is not logged in_mIf you want to run or receive an application on it. User_aIs actually Terminal_nYou are logged in at. To perform remote registration, User_aIs Terminal_nYou have to run the registration application on. A registration application is a special outgoing application that allows registration for delivery of the application. However, the design of the registration application is beyond the scope of this document. For the time being, the registered application is User_aHowever, the desired remote terminal, that is, Terminal_mAllows you to enter the identification of. The registration application then PD_UA_aAgainst Register (Term_m) Is called. PD_UA_aIs TA_mThat is, Terminal_mOperation Register (User) for the terminal agent of_a) Is called. Here again, before granting registration, TA_mBy initiating user access control for the use of this terminal, User_aMakes the user himself Terminal_mProtect the privacy of device users by checking if they are allowed to register with. User_aIf is not allowed, TA_mPD_UA in the answer that the Not Allowed state_aAnd this notifies the registration application. At this time, the registered application sends a NotAllowed message to User._aDeliver to. It is assumed that the above access control is successful. TA_mOperates for one of its SPAN Registers (PD-UA)_a) Is called. As usual, this action call is, of course, transmitted through NAP and TAP. In Figure 10, we briefly present some actions that belong to terminal mobility support in italics so as not to burden this explanation. Upon receiving this call, SPAN TD_UA_a2And TD_UA_a2Behavior for Associate_with (PD_UA)_a) To PD_UA_aCauses a save of the identifier of. TD_UA_a2At this time, Terminal_mWill continue until the registration is canceled. SPAN is OK and TD_UA_a2Identifier of TA_mAnd this also returns this same information to PD_UA_aReturn to. Next, PD_UA_aIs User_Reg_aAction against Set_Registration (TD_UA)_a2, TA_m), And this is TD_UA_a2And TA_mSave the identifier of. PD_UA_aThen returns the OK status to the registered application. The registered application is OK status Terminal_mUser_aDeliver to. This completes the remote registration. The procedure for remote registration is shown in Figure 11.<u style="single">Local deregistration</u>When a user wishes to end his or her own activity on a terminal, the user simply logs out of that terminal. This deregistration is started locally from this same terminal. Let us consider the example shown in FIG. Terminal_mUser registered in_aWants to log out. This user terminates his own access session (see Section 9.4), which results in an termination request to TD_UA. Before this end, TD_UA is PD_UA_aAction for Calls LocalDeregister (). This action request is the action Call (PD_UA) for SPAN._aConvert to .LocalRegister (). This behavior is communicated through TAP, NAP, and TA_mTo reach. Next, TA_mIs PD_UA_aAction for Calls LocalDeregister (). PD_UA_aIs User_Reg_aOperation Reset_Registration (TD_UA, TA)_m), And this is TD_UA and TA_mRemoves the identifier of from its internal table. PD_UA_aReturns status OK to TD_UA. TD_UA can now terminate itself. This procedure for local deregistration is shown in Figure 13.<u style="single">Remote registration cancellation</u>To terminate a user's own activity on one terminal, the user can also initiate deregistration remotely from another terminal. Here, User_aBut this user himself, User_mTerminal belonging to (default user)_mIn another terminal, namely Terminal_nLet's consider an example where you want to unregister from. To perform such deregistration, User_aIs Terminal_nYou must have access to the deregistration application running in and be able to enter the identification of a remote terminal (from this terminal this user wants to unregister). With this access, the unregistered application will be PD_UA_aBehavior on objects Deregister (Term_m) Is called. PD_UA_aIs TD_UA_a2That is, User_aAssigned to Terminal_mBehavior for the above terminal domain user agent Deregister (User)_a) Is called. This operation is shown by the dotted line in FIG. Physically, this is TA_mConvert to behavior against, and then TD_UA_a2Communicate via NAP, TAP, SPAN before reaching. TD_UA_a2The object is PD_UA_aRemove the identifier of PD_UA and set the OK state to PD_UA_aReturns to the object and terminates itself. PD_UA_aThe object is User_Reg_aAction on object Reset_Registration (TD_UA)_a2, TA_m) To call TD_UA_a2And TA_mCauses the removal of the identifier from its internal table. Upon receiving the OK status, PD_UA_aThe object can return an OK state to the unregistered application, which will return it to the User_aYou can also send it to. This completes the remote registration cancellation. This deregistration procedure is shown in Figure 15.<u style="single">Support for multi-terminal registration</u>As mentioned earlier, it must be possible for one user to register on several terminals and use them at the same time. To clarify this situation, consider the example shown in Figure 16. User_aIs two terminals, namely Terminal_nAnd Terminal_mRegistered with, and two terminal agents TD_UA_a1And TD_UA_a2Are associated with each. This user is Terminal_nAnd Terminal_mIt has two computational objects CO1 and CO3 running in, respectively. CO1 interacts with CO2 and CO3 interacts with CO4, where CO2 and CO4 belong to the telecom system domain. First, suppose CO1 requires the operation OpX () for CO2. This operation request is TD_UA_a1Action for Call (CO2.OpX ()). TD_UA_a1The object is then its peer object PD_UA in the telecom system domain._aThe equivalent action for Call (CO2.OpX ()), which also delivers the request to CO2. This can be done without difficulty, but it is TD_UA_a1Is PD_UA_aBecause it knows the identifier of. Similarly, CO3 can call any action on CO4 without any problems. This existing mechanism is sufficient to support calls initiated from the user domain. The reverse, that is, object CO2 invoking an action on CO1, or object CO4 invoking object CO3, requires additional information and functionality. Next, suppose CO2 requires the operation OpY () for CO1. Again, this action request is PD_UA_aAction for Call (CO1.OpY ()). The problem here is PD_UA_aDoes not know on which terminal the CO1 is located. This is the operation request TD_UA_a1Should be transferred to or TD_UA_a2I can't decide if I should transfer to. PD_UA_aIs User_aIs both terminals, that is, Terminal_nAnd Terminal_mIt has only the information that it is registered in and, User_aHas no knowledge of the location of each object in. Therefore, it is clear that such information must be supplied to it. Therefore, any object in the user domain wishing to receive a request from an object on the telecom system domain must be registered by some object in the telecom system domain, thereby PD_UA._aThe object must be able to query to get the location of that user object. A convenient place to store this information is User_Registration_aBecome an object. User agent TD_UA_a1And TD_UA_a2Must be equipped with additional behavior that allows the registration of user objects within the terminal domain. Such behavior, for example ObjReg, can have the following IDL / ODL specifications, in which IDL is defined as the interface definition language defined in CORBA and ODL allows the definition of objects. It is defined as an object definition language defined by TINA-C, which is an extension of IDL [TIN95h]. ObjReg (in ObjectId objectname, in objectId useragentname) objectname is the calculation interface identifier of the registered object. The useragentname is the user agent's computational interface identifier for where the object is registered. This argument is not needed when registration is done locally and may therefore be empty. This registration of the user agent (CO1 or CO3) can also be done by the user object itself or by some proxy object. The registration procedure for object CO1 is shown in Figure 18. User agents (TD_UA and PD_UA) act as relays for passing registration information to the User_registration object. When TD_UA receives the operation request ObjReg (objectname, TD_UAname), it calls the operation UserObjReg (objectname, TD_UAname) for the peer object PD_UA. PD_UA also calls the same behavior UserObjReg (objectname, TD_UAname) on its User_registration object. The User_registration object saves the object registration information when it receives this request. Therefore, its memory capacity must be extended to include such information. This internal data structure can be implemented in a variety of different ways. FIG. 17 shows one example. For each row of the main table, an ObjectList containing the identifiers of all the objects registered in one terminal is assigned. To further enhance this functionality, multiple object registration behavior can also be defined for each of the objects TD_UA, PD_UA, and User_Registration. The object can also be unregistered. The procedure for deregistering an object, as well as this required behavior, is quite similar to that for registration. When the action UserObjDereg (objectname, TD_UAname) is received, User_Registration fetches the corresponding ObjectList and removes the identifier of the specified object. When removing one row of the main table, that is, when performing user deregistration for one terminal, the corresponding ObjectList is also deleted. In addition to object registration and deregistration actions, the User_registration object must also have the action GetObjReg (in ObjectId objectname, out ObjectId useragentname) that other objects may use to request object registration information. It doesn't become. PD_UA when an action request Call (CO1.OpY ()) from CO2 addressed to CO1 is received and CO1 is not in the telecom system domain._aCalls GetObjReg (CO1, AgentToCall) on its User_Registration object. TD_UA_a1The identifier of is returned in the parameter AgentToCall. PD_UA_aIs TD_UA_a1You can proceed to call Call (CO1.OpY ()) to. This behavior will eventually be TD_UA_a1Communicate to, and TD_UA_a1Calls OpY for CO1. This result is returned using that same route back to CO2.<u style="single">Effect of the invention</u>The present invention provides user mobility in a distributed system. The present invention is extremely flexible because it uses agent techniques, which allow changes to the internal implementation of the agent without affecting the rest of the system. The present invention can be used in any type of network, whether fixed or mobile, public or private, local area or wide area, wired or wireless. -The present invention also allows several users to use the same terminal. -The present invention also allows one user to use several terminals at the same time. -The present invention ensures the privacy of users by recording and separating objects belonging to different users.