In this section we describe the systems engineering approach used in the project, with the necessary justifications.
The HSTN is the system design objective. It is a highly complex mixture
of hardware and software architectures. We follow a top-down approach
by decomposing the HSTN into its components: the wireless segment and the
terrestrial segment. At an intermediate level of design, these two segments
are decomposed into subordinate subsystems.
Finally we identify three distinct subsystems: EUS, NOS, SNS. These are
distinct and disjoint systems in their own. However, none of them have
a use without considering the other two. They communicate one to another
through well defined interfaces. Any changes in requirements, technology
or other factors are managed at subsystem level. This is an expression of
the information hiding principle.
The approach for designing the EUS is also a top-down one. We know what the goal is: "Design a system that is able to listen to the satellite channels, interpret the received signals, process them and display the associated information." Thus, we decide that EUS should be composed by a satellite dish, a NIC, and the appropriate software. What capabilities will each of these modules have is decided using the requirements specification. All these modules have distinct functions and communicate throudg interfaces. This makes the EUS easy to maintain and change. The same NIC and SD (hardware) will operate the old way if a new software version is installed. Conversely, a new type of SD or NIC will not change any of the software components because interaction is made through abstract interfaces. Also, compliance with international standards makes the EUS even more reliable and portable.
The NOS is a LAN. Thus, from the systems perspective it has a network architecture. This remark may be redundant but is made only for the systems engineering approach sake. The modules are the individual servers or communications equipment. They communicate using the bus/ring architectures as appropriate.
The SNS is a satellite system. From the Systems Engineering point of view, this can be viewed as a network. The modules are the satellites.
Until now we have concentrated to the subsystems design. It is the time to specificate how these components integrate into the big system. How do they communicate. The following diagrams show the information flow for the two possible scenarios: the EUS is in the same geographical are as the machine from where the information is needed; the EUS and the remote machine are in different zones. Classification of geographical zones is made with respect to the area covered by a NOS. If the remote machine is in Europe and the EUS is in USA, why use the trans-Atlantic cables for communication? We have the SNS which solves the problem in a much more elegant fashion. All long distance communication is done wireless unless moment circumstances dictate not to.
Fig 6.2 The information flow in
HSTN : same geographical area.
Fig 6.2 The information flow in
HSTN : different geographical areas.
The dashed lines represent the request of information. The solid lines show the response path. "IM" stands for Internet Machine. This "routing scheme" is intended for the High Speed Internet Access service. The other types of services provided by the HSTN are directly received from the NOS which either generates them internally or manages to obtain them from the EIS.
As opposed to classical Internet Access, HSTN offers guaranteed QOS
for its users. The quality of the HSTN is as good or as bad as its users
perceive it to be. Then it follows that the Pricing Policy should be related
to the overall user satisfaction. Accounting for individual QOS requirements
makes the network control and operation extremely complicated.
One approach can be to divide usage into classes, according to application
requirements and traffic characteristics. Then, for analytical computations,
each class can be regarded as having a representative user. This approach
ignores the heterogeneity within application classes and across users [Ref3].
Heterogeneity across time: this means that an user may have different
views for the performance of the same application at different moments
of time. Also, the overall network performance may be valued differently
along the time axis.
Heterogeneity across users:One of the requirements of the HSTN is
worldwide coverage. This is easily translated into number of users of the
order millions. It is then apparent that different users may perceive the
QOS in different ways. This remark is related to the individual interests
in one of the others services provided by the HSTN.
In conclusion, the user's feedback is seen as a very important quantity
of interest in determining the pricing policy. Feedback schemes are then
necessary to implement, that is, a major emphasis will be on increasing
the level of intelligence at EUS level.
A prototype of the system will first be constructed. The capabilities of this prototype will be verified in various operating conditions.
The following subsystems will be part of the prototype:
The following figures summarize the verification scenario. It consists of three steps:
Steps two and three are accomplished be simulating the load directly in the NOS. Dummy transactions are generated in the NOS. One real user is in operation in all these steps.
The goal of this step is to check if the system design complies with the requirements specification. It is the final step before operations start. It also a difficult step given the size of the system.
