Many points need to be investigated further. A s part o f the project's future work the follow in g items can be mentioned.
> A s m entioned in Chapter 6 (Section 6.1.1.2), som e procedures specified in Chapter 4 that have not been im plem ented in the simulation need to be further analysed.
■ N ode and link failure. The basic m echanism is the same as for the case o f m anagement re configuration that has been simulated and fully tested. There are, however, som e extra considerations due to delays in reconnecting the isolated nodes to new parents and in establishing com m unication with the old parent. The procedures for hardware failure detection, for reconnection o f isolated nodes and for the establishment o f the direct link witli
old parent can be designed so as to m inim ize the time interval for which parentless children
remain isolated. However, this time interval cannot be totally eliminated. Therefore, tlie parentless child node needs to be able to evaluate the accuracy o f its database according to the tim e interval between detection o f hardware failure and reconnection to new parent. Further studies on the significance o f this delay and its effect on the accuracy o f tlie reconnected n ode’s database and on the restoration procedure are needed.
■ Introduction o f new local exchanges. The designed recovery procedure does not include
restoration on demand for location change requests so as to keep the procedure sim ple and avoid the introduction o f an extra flag to the location change request packet. The simulation w ould help in evaluating the consequences o f this design decision and in studying alternative procedures, i f necessary.
■ Proposals for limiting the depth o f the flood fill packets spread. The m echanism remains effectively the same as the original one that has been simulated and fully tested, only it is now lim ited to a sub-tree o f the network. The implementation o f this case in the simulation would allow the measurement o f the performance gain achieved by lim iting the spread o f propagation o f the flood fill packets and would help in studying alternative or additional m ethods for achieving further performance gains. This performance gain should reflect the reduction in signalling propagation throughout the system and the decrease in the probability o f clashes occurring between recovery procedures and ordinary requests or other simultaneous recovery procedures, and hence avoiding further unnecessary recovery procedures.
> The monitoring and decision-m aking m echanism s proposed as part o f the dynam ic management re-configuration procedure (Chapter 5) need to be tested. The simulation o f these mechanisms should help in testing their feasibility and in defining and refining the follow ing points;
■ procedures for collection, dissemination and update o f state data,
■ definition o f which nodes should take decisions on when and how to re-configure,
■ amount o f state information (size o f network subset) that should be held by the decision making nodes,
■ strategies for avoiding the creation o f single points o f failure (what to do in case a decision m aking node fails),
■ definition o f how often the network should re-configure, if it should respond to daily traffic variations or if it should re-configure according to long-term ones,
■ procedures on how the decision-m aking nodes can interpret the available information in order to determine which nodes should reconnect and w hich parts o f the network they should
reconnect to (on which parameters should the decision be based).
> The methods for optimization o f the network topology, described in Chapter 5, need to be applied for different usage patterns and database capacity constraints and its effectiveness needs to be
tested.
> As discussed in Chapter 3 and in the previous section, REM US does not represent, in its present form, a full solution to any particular apphcation. The implementation o f a particular application using REM US approach as the basis should provide invaluable information about the suitabilit) and applicability o f such a distributed strategy. The personal mobility service should be a natural candidate since it has been used as the underlying application for the system simulation. As
discussed in Section 3.6, this application requires the provision o f two distinct services: a strategy for user location and the m anagement o f the user profile data. Those two aspects o f the personal m obility service cannot be tackled separately as they have conflicting requirements and hence a com prom ising solution has to be found. REM US can provide a strategy for user location. The strategy for profile management should then follow a distributed approach so that the necessary information for handling incom ing and outgoing calls can be found locally and hence the scalability o f the system is not compromised. Therefore, the follow in g points need to be investigated further.
■ Security issues and the data management aspects o f the problem (custom er profile management strategy, size o f user profile, optimum file location, rephcation strategy, signalling load generated due to file transfers, e tc ...) need to be defined. The solution probably consists o f a com bination o f different techniques. One possible solution is to keep the customer's profile at the hom e base address, the parts, however, that are most constantly accessed can be m oved along with the customer. I f more information than what is being transferred is needed, then the customer's full profile can be accessed at the hom e base location. To make the retrieval o f the profile information faster, a pointer {i.e. home base address) to the profile file location can be transferred along with the customer's information or the hom e base location could be “partially” encoded in the customer's personal number. “Partially encoded” means that enough information is present to make the search faster but not too m uch to make the personal number loose its flexibility and its immutability. The exact
balance am ong the different conflicting techniques is hard to define, the simulation should help in identifying the optimum approach. It is expected that a hybrid solution that lies between the two extrem e approaches, centrahzed and distributed, might represent the com prom ise am ong the various conflicting requirements.
■ Variations in the network topology could help in optim izing the system according to this
particular apphcation. Many hierarchical system s make use o f interconnections am ong nodes
at tlie sam e level. Those interconnections are often used as bridges to bypass the liierarchy o f the system and be able to send m essages directly. This feature could be used in conjunction w ith the partial encoding o f the home base location into the personal number (see first item above) in order to allow big jum ps to be made within the network hierarchy so that the request is sent directly to the region where the probability o f finding the customer is higher. The extra m anagement overhead necessaiy to im plem ent this idea needs to be evaluated against how m uch can be gained in terms o f efficiency.
■ There are two procedures that need to be specified: the registration o f a new custom er and the
checking o f the validity o f a dialled number. The two procedures are interconnected in that the difference between valid and non-valid numbers might be determined by the registration procedure. The difficulty in tackling these two problems arise from the fact that no one node know s about the entire list o f customers registered in the system , the information is distributed. Even the root cannot distinguish am ong the follow in g options: lost information, a number being first requested between two sub-networks or a non-valid number. There are no area codes or other type o f information encoded in the numbers that can help in differentiating a valid from a non-valid number (the partial encoding o f information in the personal number, m entioned in the first item o f this section, might help in detecting non-vahd numbers). If no special procedure is designed, a non-valid number that is repeatedly dialled can cause repeated recovery procedures to be performed, significantly increasing the load on the network and hence wasting network resources.
REM US can be tested in other applications. As mentioned in Section 3 .6, REM US is suitable for an environment such as the Internet, which is based on a highly distributed physical structure, interconnecting disparate independent networks. The scope for a system such as REM US is im mense. For exam ple, REM US is a candidate to act as a UR N resolver, as specified in Section 2.5.4. W ithin an open distributed processing environment such as CORE A [29], the naming system plays an important role, particularly if m obility support is introduced. REM US represents a candidate for the implementation o f the Nam ing Service for the CORE A system. REM US can be used as a general name resolution system, integrating legacy and newly introduced naming system s over heterogeneous networks or it can be optim ized to resolve particular name schemes,
serving specific apphcations.