T Rec Y.110 199806 I!!pdf e

INTERNATIONAL TELECOMMUNICATION UNION
ITU-T
TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU
Y.110
(06/98)
SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE General
Global Information Infrastructure principles and framework architecture
ITU-T Recommendation Y.110

(Previously CCITT Recommendation)
ITU-T Y-SERIES RECOMMENDATIONS GLOBAL INFORMATION INFRASTRUCTURE
General Services, applications and middleware Network aspects Interfaces and protocols Numbering, addressing and naming Operation, administration and maintainance Security
Y.100Y.199 Y.200Y.299 Y.300Y.399 Y.400Y.499 Y.500Y.599 Y.600Y.699 Y.700Y.799
For further details, please refer to ITU-T List of Recommendations.
ITU-T RECOMMENDATION Y.110 GLOBAL INFORMATION INFRASTRUCTURE PRINCIPLES AND FRAMEWORK ARCHITECTURE
Summary This Recommendation presents the basic concepts of the Global Information Infrastructure (GII). It describes a number of models which can be used to represent the functional entities involved in the provision of the GII, and their interrelationships, from a variety of perspectives or view points.
Source ITU-T Recommendation Y.110 was prepared by ITU-T Study Group 13 (1997-2000) and was approved under the WTSC Resolution No. 1 procedure on the 12th of June 1998.
Keywords architecture, functions, framework, GII, Global Information Infrastructure, models, standardization standards.
FOREWORD ITU (International Telecommunication Union) is the United Nations Specialized Agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of the ITU. The ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Conference (WTSC), which meets every four years, establishes the topics for study by the ITU-T Study Groups which, in their turn, produce Recommendations on these topics. The approval of Recommendations by the Members of the ITU-T is covered by the procedure laid down in WTSC Resolution No. 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC.
NOTE In this Recommendation, the expression "Administration" is used for conciseness to indicate both a telecommunication administration and a recognized operating agency.
INTELLECTUAL PROPERTY RIGHTS The ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. The ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, the ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database.
ITU 1998 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU.
ii
Recommendation Y.110
(06/98)
CONTENTS Page 1 2 3 4 5 5.1 5.2 6 6.1 Introduction ................................................................................................................ Scope .......................................................................................................................... Terms and references.................................................................................................. Objective and principles of the GII ............................................................................ User perspective of the GII......................................................................................... Features of the users viewpoint of the GII................................................................. Conceptual overview of the GII and its users............................................................. Simple enterprise model............................................................................................. Purpose of the enterprise model and its terms and definitions................................... 6.1.1 6.1.2 6.2 6.2.1 6.2.2 6.2.3 6.3 6.3.1 6.3.2 6.3.3 7 7.1 Purpose of the enterprise model.................................................................... Semi-formal definition of enterprise modelling terms.................................. Roles and players .......................................................................................... Structural roles .............................................................................................. Infrastructural roles within the GII................................................................ General features of relationships between roles............................................ Example configuration of structural roles..................................................... Example configuration of infrastructural roles ............................................. 1 1 1 1 2 3 5 6 6 6 7 8 8 8 9 11 11 12 12 13 13 13 14 15 17 17 18 18 18 20 21 21 21
Concepts in the simple enterprise model....................................................................
Features of relationships between roles......................................................................
GII structural model ................................................................................................... Purpose of the structural model and its terms and definitions ................................... 7.1.1 7.1.2 Purpose of the structural model..................................................................... Semi-formal definition of terms in the structural model............................... Types of application components of the GII................................................. Types of services of the GII.......................................................................... Application component invoking and handling service................................ Baseware service components....................................................................... Middleware service components................................................................... Domains and contracts .................................................................................. Service provisioning platforms .....................................................................
7.2
Structure of services and applications ........................................................................ 7.2.1 7.2.2 7.2.3
7.3
Infrastructural service components............................................................................. 7.3.1 7.3.2
7.4
Domains and service provisioning platforms............................................................. 7.4.1 7.4.2
(06/98)
iii
Page 8 8.1 GII functional model .................................................................................................. Purpose of the functional model and its terms and definitions .................................. 8.1.1 8.1.2 8.2 8.3 8.4 Purpose of the functional model ................................................................... Semi-formal definition of terms in the functional model.............................. 21 21 21 22 23 23 24 24 25 26 28 29 29 29 30 31 31 32 34 35 36 38 38 39
Impact of distributed applications on the functional model ....................................... Domains and service provisioning platforms............................................................. Functions and logical interfaces in the GII................................................................. 8.4.1 8.4.2 Types of functions and logical interfaces...................................................... Functions and roles .......................................................................................
8.5 8.6 9 9.1
Network functions and the network operators domain.............................................. Transparency of middleware and application protocols............................................. GII implementational model....................................................................................... Purpose of the implementational model and its terms and definitions....................... 9.1.1 9.1.2 Purpose of the implementational model........................................................ Semi-formal definition of implementational modelling terms......................
9.2 9.3
Segments in the implementational model .................................................................. Segments in telecommunications networks ............................................................... 9.3.1 9.3.2 9.3.3 9.3.4 Structuring of implementation possibilities in the example.......................... Information appliance configurations ........................................................... Access segment configurations..................................................................... Variety of telecommunications network segments and their interconnection
Appendix I The relationship of socio-economic issues to standards.................................... I.1 I.2 The configuration of information society and its role................................................ ITU involvement in the GII........................................................................................
iv
(06/98)
Recommendation Y.110 GLOBAL INFORMATION INFRASTRUCTURE PRINCIPLES AND FRAMEWORK ARCHITECTURE (Geneva, 1998) 1 Introduction
The Global Information Infrastructure (GII) enables people to securely use a set of communication services supporting an open multitude of applications and embracing all modes of information, any time, anywhere, and at an acceptable cost and quality. The GII also supports the goal of an international consensus on common principles governing the need of access to networks and applications and their operability based on a seamless federation of interconnected, interoperable communication networks, information processing equipment, databases and terminals. 2 Scope
This Recommendation is designed to be a high-level systems engineering document presenting concepts needed to support the realization of the GII. However, it is not expected to present all inclusive detailed specifications for the GII. Rather, this Recommendation is intended to be used as a background document for use by ITU Study Groups and other groups outside the ITU to use as input for their development of detailed standards for critical functionalities required to support the enhancement of the GII. In support of identifying the functionalities required to support the enhancement of the GII, GII functional entities and their relationships are described. This functionality-based view of the GII will also need to be balanced with physical aspects (e.g. the results of the use of the scenario-based approach discussed in Recommendation Y.120), resulting in the development of GII functional models consisting of functional entities and reference points. It is hoped that these GII models will effectively represent a functional perspective from which numerous physical views can be developed. 3 Terms and references
For further study. 4 Objective and principles of the GII
The objective of the GII is to ensure that each citizen may eventually gain access to the information society. This can be enabled by the interoperability of networks, information processing systems and applications. These objectives will be served by the following core principles of the GII which will: promote fair competition; encourage private investment; define an adaptable regulatory framework; provide open access to networks,
(06/98)
while: ensuring universal provision of and access to services; promoting equality of opportunity to the citizen; promoting diversity of content, including cultural and linguistic diversity; recognizing the necessity of worldwide cooperation with particular attention to less developed countries. promotion of interconnectivity and interoperability; developing global markets for networks, services and applications; ensuring privacy and data security; protecting intellectual property rights; cooperating in R&D and in the development of new applications; monitoring of the social and societal implications of the information society. User perspective of the GII
These principles will apply to the GII by means of: 5
In accordance with the general aim of this Recommendation to give information on where more detailed standardization is appropriate, this clause identifies some of the more important aspects of the GII as seen from the users of the GII in particular, the services offered and applications supplied by the GII. The motivation in the clause is as follows: Standardization of technical interfaces is only appropriate where the technical interface can be part of an overall interface between two distinct organizations. As several historically separate industries converge, organizational boundaries will evolve and so the places where standardization is required will also evolve.
The background is one of convergence between a number of industries particularly the telecommunications industry, the computing/information technology industry, and the entertainment/consumer electronics industry. The GII is at the centre of the convergence and is fully expected to expand over time as illustrated in Figure 5-1.
(06/98)
TODAY Computer/ Information NEAR FUTURE Computer/ Information Consumer/ Entertainment GII Consumer/ Entertainment
T1311570-97
Telecommunication GII
Telecommunication AIM Computer/ Information
GII Telecommunication Consumer/ Entertainment
Figure 5-1/Y.110 GII is at the centre of the threefold industrial convergence
5.1
Features of the users' viewpoint of the GII
There are many interested groups with a view on the GII as illustrated in Figure 5-2. The viewpoint of groups will be different and will tend to emphasize aspects which are important to that group. By examining the GII from these multiple perspectives, a progressively more complete understanding can be obtained with the added consideration of each view.
End users perspective
Telecommunications industrys perspective
Regulators perspective
GII
Information technology industrys perspective

T1311580-97
Standards bodies perspective
Broadcast entertainment industrys perspective
Figure 5-2/Y.110 Examples of viewpoints on the GII
(06/98)
The simple enterprise model can be used to identify some of the features required of the GII by users, and also the way in which they will interact with the features. The following list illustrates some of the manners by which GII users might need to interact with the GII: GII users may need to be able to "see" (i.e. be aware of) only the GII users with whom they are really interested in forming a relationship. In this context, applications would be "seen" as components of the sought relationships, without concern for the services supporting these relationships or to other involved GII users (as illustrated in Figure 5-3); GII users may need to be able to "see" (i.e. invoke and use) applications without concern for the services supporting the applications or to other GII users involved in the applications and in the provision of involved services (also illustrated by Figure 5-3); GII users may need to be able to "see" (i.e. invoke and use) applications, while at the same time being concerned with being aware of or choosing some of the: services that may be supporting the applications; and/or some of the GII users involved in the applications and/or involved in the provision of involved services (as illustrated in Figure 5-4).
communication networks and services

info r app mation lian ce
GII
T1311590-97
Figure 5-3/Y.110 A user view which is transparent to the services supplied by the infrastructural roles of the GII
(06/98)
communication networks and services
Private networks B-ISDN ISDN information appliance
PS D N CATV
info app rmati lian on ce
other network types information appliance
inform a applia tion nce
The difference is the way in which the infrastructure is visible to the user. In the first case, the service provider chooses to include the provision of infrastructural services as part of its service (800 service is a simple example), while in the second case, the end user takes responsibility for the provision of at least some of the infrastructural services. 5.2 Conceptual overview of the GII and its users the people that create, produce, use and operate information; the information appliances that are used to store, process, and allow access to information; the communications infrastructure which transports the information between geographically separated information appliances; the information which includes application software such as home shopping systems, games, etc., as well as video, audio, textual, and graphical information which may be converted from an existing medium into electronic form for use by GII users.
Figure 5-5 gives a conceptual overview of the GII and its users. It identifies four basic elements:
These basic elements interact as illustrated in Figure 5-5.
n io at rm ce fo an in pli ap
LA N GII
ion rmat info nce ia appl
T1311600-97
Figure 5-4/Y.110 A user view which includes the services supplied by the infrastructural roles of the GII
(06/98)
People
People
Encyclopedia
Video film
Information Application support platform Communications support platform Information appliance
Information Application support platform Communications support platform Information appliance

T1311610-97
Communications network
Communications network
Communications infrastructure
Figure 5-5/Y.110 Conceptual overview of the GII and its users
6 6.1 6.1.1
Simple enterprise model Purpose of the enterprise model and its terms and definitions Purpose of the enterprise model
The primary purpose of the enterprise model is to identify interfaces which are likely to be of general commercial importance. In order to do this, a number of roles are identified which describe a reasonably well-defined business activity which is unlikely to be subdivided between a number of players. In addition, it should be anticipated that the roles would have a reasonably long existence. The interfaces surrounding the role must persist for some time in order that customers and suppliers of the role can successfully interact with it. In addition, many players may choose to take on the same role in which case the role becomes a competitive activity; also, the role needs to be reasonably stable for a successful competitive marketplace to emerge. Each role can be thought of as adding value to the various inputs it buys from suppliers. The role then passes its output to its customers. These roles can be individually described and then linked to form value chains. The value chains of roles represent the "industries" which produce the end product for the end user. This is illustrated in Figure 6-1.
(06/98)
Role
Role
Role
Role
added value
added value
added value
added value
goods or service consumed by end user
intermediate goods or service
T1311620-97
Figure 6-1/Y.110 Enterprise model
In understanding the roles and the nature of the goods and services flowing between them, it is possible to identify more generic features which are needed to support the roles and the interfaces between them. As well as the goods and services, other entities must pass between roles including: 6.1.2 information; contractual and legal obligations. Semi-formal definition of enterprise modelling terms
6.1.2.1 role: The role is a business activity which fits in a value chain. The role is constrained by the smallest scale of business activity which could exist independently in the industry and so a marketplace will exist for every relationship between roles. 6.1.2.2 value chain, complete value chain, and primary value chain: A "tree" of roles are connected together to make an end-goods/service. The total set of roles involved in producing an end-goods/service and the way they pass intermediate goods/services between the roles is called the complete value chain. The set of roles which form the only principle activity of a generally recognized industry which produces the end-goods/service are the primary value chain. All the other roles in the complete value chain will be providing support goods/services for roles in the primary value chain. 6.1.2.3 structural role: A structural role is a role in the primary value chain of an industry. A structural role will therefore involve a business activity which is directed towards that industry and, in general, only towards that industry and the output goods/services of a structural role will be directed, in general, only to the next structural role in the primary value chain. 6.1.2.4 infrastructural role: An infrastructural role is not in the primary value chain of the industry which is under consideration, but supplies goods/services for one or more roles to the primary value chain of that industry. The business activity of an infrastructural role will normally be directed towards many other roles, even roles belonging to more than one primary value chain. The output goods/services of an infrastructural role are likely to be based on reusable components in order to meet the requirements of its many customer roles. However, an infrastructural role may itself belong to a primary value chain within its own industry and therefore be a structural role from the perspective of its own industry. From the perspective of the roles which it is supplying, it is an infrastructural role. 6.1.2.5 player: A player is an organization, or individual, which undertakes one or more roles. The player can be a commercial company, a government agency, a non-governmental organization, a charity or an individual.
(06/98)
6.1.2.6 relationship between roles: When intermediate goods/services are passed from one role to the next in a value chain, there is a relationship between the roles. The relationship implies that a marketplace exists which can match players who undertake the role on one side of the relationship with players who undertake the role on the other side of the relationship. Some players may choose to be integrated and undertake both roles, in which case the relationship is within the players domain. 6.1.2.7 horizontal relationship: This is the relationship between two adjacent roles which are in the same primary value chain. The roles are therefore in the same industry. A horizontal relationship can also be called a structural relationship. 6.1.2.8 vertical relationship: This is a relationship between two roles which are not in the same primary value chain. One role will be supplying goods and services in order to provide some of the infrastructure required by the structural role. 6.1.2.9 segment: A segment is the entity which is common to the enterprise modelling, the structural modelling, and the functional modelling. A segment is part of one role, owned and operated by one player, part of one (and only one) service provisioning platform, and part of one domain, and is composed of a well-defined set of functions. 6.2 6.2.1 Concepts in the simple enterprise model Roles and players
The first distinction made in the simple enterprise model is between roles and players. A role is a reasonably well-defined business activity and will form, along with other roles, a value chain by which goods can be produced for end users. A player is a defined organization, for example, a company or government body, which undertakes one or more roles. The simple enterprise model is concerned only with roles. This method of definition allows a clear translation from business activity to the relationships which may be the subject of standardization. 6.2.2 Structural roles
Structural roles are roles which are all directed towards a particular product or set of products. They normally are set in a chain, called the primary value chain, which starts with the raw materials for the product and ends with the retailing of the product to end users. The information industry has a set of structural roles which form a primary value chain including: Information ownership role There is frequently value in owning the source of information; for example, a gallery owns pictures images of which can be sold. Provision of information and related content role This role takes raw information and makes it available for inclusion in information services and information-based services; for example, it could provide a library of photographs which could be used by travel agents in describing their services. Provision of information-based services role The role builds information and informationbased services which it makes available to end users. This includes services which deliver goods or information for example, a yellow pages service and also includes services where information is only part of the service for example, home shopping where, in addition to the information transactions, physical goods must be delivered to the end user. End user role The end user can be either a private individual or a role in another industry which requires information-based services.
(06/98)
These roles are undertaking a wide variety of activities which are often referred to, in functional terms, as applications. They are of interest to the GII in that it is important that the infrastructural roles of the GII understand the business activity of the role which they are supplying. The main focus of the GII is on the infrastructural roles which supply the full range of support services which these roles require in order to carry out their activity. By their definition, the structural roles of the GII are only concerned with business activities directly associated with information content and its application, while the infrastructural roles of the GII are concerned with all the activities which allow the structural roles of the GII to create, format, contextualize, store, find, sell, display, etc., their content and its application. These structural roles, as well as the relationships between them, require support services and these are supplied by infrastructural roles. The GII can, therefore, be defined in terms of the set of roles which supply support services to the structural roles of the information industry. Moreover, these structural roles of the information industry are the users of the GII. This is illustrated in Figure 6-2.
EUR
PISR
PICR
IOR
structural roles
support
Global Information Infrastructure
infrastructural roles
T1311630-97
EUR PISR PICR IOR
End User Role Provision of Information-based Services Role Provision of Information and related Content Role Information Ownership Role
Figure 6-2/Y.110 Structural roles as the users of the GII
The structural roles are not themselves part of the GII they require the GII to carry out their role. For example, the provision of information and related content role may own the copyright of a film and wish to sell viewings of the film through service providers (players undertaking the provision of information-based services role). In order to do so, the film must be mounted on a media accessible by service providers, for example, a video server. The ownership of the copyright, which is the basis of the structural role, is not part of the GII; however, the ownership and operation of the video server together with services to access the server are part of the GII. 6.2.3 Infrastructural roles within the GII
It is possible to identify a number of roles in the GII; these are illustrated in Figure 6-3.
(06/98)
Terminal equipment supply
Communication and networking of information
Application/ service creation support
Generic communications service provision
Distributed information processing and storage service provision
T1311640-97
Figure 6-3/Y.110 Infrastructural roles within the GII
Communication and networking of information This role provides a general, distributed platform on which information applications and services can be supported. It provides the means by which an application and its users can be distributed without being aware of the nature of the distribution. It will invoke the application when requests are sent to it, support messaging to and from the application and also between components of an application. It will include capabilities to support directory services, navigation, security, payments, browsing and searching, etc. Distributed information processing and storage service provision This role provides a processing platform on which applications can run and can store data. This role will involve the use of an information appliance. Generic communications service provision This role provides telecommunications services for the transport of data, voice and video. Service and application creation support This role supplies features which facilitate the production of services and applications which can use communication and information networking. Terminal equipment supply This role supplies information appliances to end users which can form an integral part of the distributed platform operated by communication and information networking. These roles are infrastructural from the perspective of the structural roles of the information industry. They form into value chains in both in the way they contribute infrastructural goods and services to the information industry and also when they supply goods and services to other industries or directly to end users. An example of the last case in the traditional telecommunications industry where the generic communications service provision can supply a telecommunications retailing service provision role to form the value chain of the traditional telecommunications industry.
10
(06/98)
6.3 6.3.1
Features of relationships between roles General features of relationships between roles
The general configuration of the relationship between roles is illustrated in Figure 6-4. Both the structural roles and relationship between them is supported by the GII.
structural role
relationship
structural role
structural roles
support
Global Information Infrastructure
infrastructural roles
T1311650-97
Figure 6-4/Y.110 Structural roles as the users of the GII
The relationship between the roles is commercial and so there is a customer side and a supplier side to the relationship. In addition, this relationship needs to be supported by brokerage and management services. These enable a customer to find a supplier and a commercial transaction to be negotiated and completed, respectively. This is illustrated in Figure 6-5. The services of the GII should be able to support these relationships.
brokerage
role
customer aspect of structural role
supplier aspect of structural role
role
T1311660-97
management
Figure 6-5/Y.110 The relationship between roles
(06/98)
11
Since there can be more than one player undertaking the customer role and more than one player undertaking the supplier role, a relationship between roles also represents a competitive marketplace. This marketplace trades the intermediate goods/services that are passed between the roles and establishes the price at which they are traded. 6.3.2 Example configuration of structural roles
Since a structural role is defined by a business activity which is part of an industry, it is concerned with applications of the GII. (Note that applications also have a similar definition to business activity or "virtual job" between end users.) An application is therefore made up of activities and the relationships between activities. For example, news-on-demand is an example of a typical application as are other on-demand applications such as movie-on-demand, on-demand-library etc. In the news-on-demand application, users are able to retrieve electronic newspapers which they can browse and read. In this example, there are the end users whose activity is browsing and reading the news. The end users retrieve the news form information service providers whose activity is providing the end users with access to the different electronic newspapers in such a way that the end users can browse and read the news. They also charge the end users for the service including any payments for the new content. There are news content providers which can be conventional newspapers, news magazines, or news agencies which provide the news content to the information service providers. There are finally the news content creators who are the journalists, photographers, artists, etc. who create the content which can be browsed and read by the end users. All these structural roles use various infrastructural services. In this way the structural roles are the users of the GII, and therefore outside the scope of the GII. 6.3.3 Example configuration of infrastructural roles
An infrastructural role is defined as a role which supplies goods and services in support of the primary value chain, generally using reusable service components. This means that the GII infrastructural roles address the service components and their associated systems which supply the information applications. The infrastructural roles are characterized by these service components and systems, and include their ownership and operation. Figure 6-6 illustrates some of the more commonly recognized systems with information and telecommunications systems and shows how they relate to the scope of the GII.
12
(06/98)
Scope of structural role of the GII
User application
News on demand Voice information (Message) Application
Contents DB
Navigator, Remote Controller
Application support function Service
VOD, Telephony, Facsimile etc. Authentification, Security, Routing etc. Service control & management functions Signalling functions
Application support function Service Service support function
L2 G/W DBM S
MPEG, JPEG HTML, Handset
Service support function
L1 G/W ARS
DOS, Windows Modem, DSS No. 1 User access function Keyboard Mouse
Communication & Processing Function
Switching functions
Comm unication & processing function
PABX router
Transmission functions Connector terminator Repeator
Scope of Infrastructral Role of the GII DBMS HTML JPEG G/W MPEG DataBase Management System HyperText Markup Language Joint Photographic Experts Group Gateway Motion Picture Experts Group
T1311670-97
Figure 6-6/Y.110 Example configuration of infrastructural roles in the GII
GII structural model
NOTE The structural model is concerned with services and the way GII services are supplied to structural roles. The terms "structural role" and "structural model" should therefore be regarded as separate concepts. The more detailed relationship between these concepts is for further study.
7.1 7.1.1
Purpose of the structural model and its terms and definitions Purpose of the structural model
The structural model identifies the services and the supply of applications, the way these are offered by roles, and the way in which roles can be organized in order to offer services and supply applications. This is illustrated in Figure 7-1.
(06/98)
13
resource service offered or application supplied to clients service resource resource Role service offered or application supplied to clients service resource resource Role
T1311680-97
resource
resource
resource
Figure 7-1/Y.110 Structural model
In order to offer services or supply an application, a role must bring together a number of resources and package them into a service which is applicable to its clients. Each resource brought in, or operated by a role, may well be supplied by another role and therefore be the service of another role. As a role adds value, it can package together services or applications from other roles and either build them into completely new services or applications or simply provide a packaging service. For example an electronic payments service will use many telecoms services and many processing and storage services, however, these are not apparent to the user of the electronic payments service. On the other hand, a user of telephone banking may well be aware of the freephone telecoms service which has been packaged in to provide the service. 7.1.2 Semi-formal definition of terms in the structural model
7.1.2.1 service: In order to pass value up a value chain, a client role requests and invokes service from a supplying role. Service is characterized by the transactions which take place between the roles, and generally the client role will request service for each item of value it requires. Watching a film at the cinema is an example of purchasing a service. Where a service is offered between roles undertaken by different players, the service will be offered in the context of a contract and must contain sufficient features in order to ensure that the contract can be fulfilled and verified. 7.1.2.2 application1: An application is similar to a service; however, with an application, the client buys the full rights to usage and so the product can be reused many times by the client. Buying the video of a film is an example of purchasing an application. With this definition, the supply and support of an application is undertaken by an infrastructural role while the operation of an application is undertaken by a structural role. As a result, an application, once in operation, will become a user of infrastructural services and therefore becomes part of the user domain. ____________________
1
ITU-T SG 13 noted that there are many definitions of the term "application" across ITU-T Study Groups and ISO subcommittees. As a result, this definition may not completely align with those definitions. Recommendation Y.110 (06/98)
14
NOTE In the converged GII, the distinction between services and applications is important not just because they reflect the two different commercial arrangements but also because they reflect the fact that the telecommunications industry has traditionally offered services while the information technology industry has traditionally offered applications.
7.1.2.3 application component: An application component is a part of an application. When an application is distributed across several geographically separated information appliances, the application will be formed into a number of application components. These will interact with each other using the services of the GII. In addition, an application may be split into application components in order to simplify the design of the application and may result in more that one application component of the same application being resident in the same information appliance. 7.1.2.4 domain: A domain is the collection of segments which are owned and operated by a player and can include segments from more than one role. The extent of a domain is defined by a useful context and one player can have more than one domain; however, a domain should not include more than one service provisioning platform. 7.1.2.5 service provisioning platform: A service provisioning platform is the basis for offering a service. It is formed from a number of segments which are required to offer the service. These segments can be drawn from a number of role instances and therefore can be made up from a number of cooperating domains. 7.1.2.6 contract: When two related roles are undertaken by different players, a contract is agreed to set the framework between the two players. In the case when the two players are commercial organizations, then the contract will be a commercial contract. When a relationship between roles involves a contract, the relationship must take on the extra features associated with the contract. 7.1.2.7 service interface: A service interface is the means by which a service is used by a player. The service interface will have several aspects including the inter-role relationship, information and computational aspects, implementational aspects, and when the interface is also between players contract aspects. If the service involved the delivery of any physical goods, this must also be included in the service interface. 7.1.2.8 service components: Service interfaces can be complex and can be made up from a number of service components which may also be optional in the service interface. 7.1.2.9 segment: A segment is the entity which is common to the enterprise modelling, the structural modelling and the functional modelling. A segment is part of one role, owned and operated by one player, part of one (and only one) service provisioning platform, and part of one domain, and is composed of a well-defined set of functions. 7.2 Structure of services and applications
Users may wish to either use the services of the GII directly or they may wish to operate their own applications and then use the services of the GII in support of these applications. In addition, components of the user's applications can be supplied and supported by the GII. The services and applications supplied by the GII are built up in the form of service and application components. These components are them packaged together in order to create the actual service or application delivered to the user. This is illustrated in Figure 7-2.
(06/98)
15
Users and their applications
Infrastructural services and applications
e-mail
file transfer
distributed co-operative working
home shopping Telephony video conferencing
video on demand
Middleware services and applications
security billing browsing & searching authentication format translation directory navigation post office conference bridge payments Middleware functions Telecoms services and applications
Processing and storage services and applications
PSTN/ N-ISDN Internet Mobile TBN CATV
B-ISDN
PC File server STB
SCP
DBSN Video server PSDN
Transaction processor
Telecommunications functions TBN Terrestrial Broadcast Network DBSN Direct Broadcast Satellite Network
Processing and storage functions

T1311690-97
Figure 7-2/Y.110 Services and application supply in the GII
16
(06/98)
Notes relative to Figure 7-2:

NOTE 1 This figure should not be regarded as a "layer" diagram and should be understood in the context of Figure 7-1. NOTE 2 Many individual flows are not shown on this diagram as it is indicating the main flows in bringing together the resources required to create infrastructural services.
The GII brings together the resources of the GII, network resources, processing and storage resources, and middleware resources in order to offer services and supply applications to the users. The services and applications are built up from components, sometimes referred to as building blocks. These components are associated with the capabilities of the resources and so it is possible to describe the services and applications in terms of these components. The supply of infrastructural services will depend on the level of sophistication developed in the infrastructural roles. In the early days of the GII, these are likely to be relatively simple and users of the GII are likely to buy application components even for basic requirements. However, as the GII develops, these requirements along with many new features will be available as services from the more sophisticated communication and networking of information role in the GII. In so doing the application components associated with these features will become middleware resources and this will be a general trend over time. This is illustrated in Figure 7-3.
Applications infrastructural services supporting applications migration of application components to middleware Infrastructral services based on middleware resources
Network, processing and storage resources
T1311700-97
Figure 7-3/Y.110 Migration of application components to middleware
7.2.1
Types of application components of the GII
The range of applications, or more particularly, application components, that are supplied by the GII are as varied as the applications of the GII. It therefore is inappropriate to make any early classification of application components, as these will evolve rapidly with time, and in any case are more appropriate for consideration by those who are experts in each application. However, application components, if well-designed, are frequently reusable by other applications. In this case, they can become middleware components and form the basis for new services and new applications of the GII. This again suggests the general migration, over time, of application capabilities to middleware as illustrated in Figure 7-3. 7.2.2 Types of services of the GII
The range of services which can be offered is wide and can be dynamic as the available resources can be combined in many different ways. It therefore is appropriate to classify the service components rather than the services. Each service component will be more directly related to the resources required for the service component.
(06/98)
17
Infrastructural service components are the full set of service components for GII services. Most of these components are likely to give "high-level" capabilities such as security service components and they often require the use of many other distributed resources. In addition to these more sophisticated service components, they will include middleware and baseware service components as well. Middleware service components will, in general, use middleware and baseware. These service components include interworking capabilities. Baseware service components are divided between network service components, processing and storage service components. In general, network service components will use only network resources while processing and storage service components will use only processing and storage resources. These service components are elaborated in more detail in 7.3, 7.4, and 7.5, respectively. 7.2.3 Application component invoking and handling service
A particular service or service component which is essential to all applications is the ability to run an application component. An information appliance, as part of its basic capability must be able to mount, invoke and handle an application component as illustrated in Figure 7-4. Once mounted and invoked, an application component can then interact with other application components and request services of the GII.
Application component
Application component invoking and handling service Middleware resources
Access to network resources Information appliance
Processing and storage resources
T1311710-97
Figure 7-4/Y.110 Application component invoking and handling service
7.3 7.3.1
Infrastructural service components Baseware service components
Baseware service components support the functions which in turn support the higher level service components offered in the middleware service categories. In particular, they support the provisioning of generic communications service components and distributed information processing and storage service components. These include all the telecommunications networks and processing and storage platforms mentioned in clause 9.
18
(06/98)
Baseware service components can be categorized into three groups of service components. The first group is concerned with basic transport information, the second with basic processing and storage, and the third is concerned with the control and management of these basic transport and processing and storage service components. In defining baseware service components, it has been assumed that a service which requires interconnection of the same network type across different domains is a baseware service. A service which requires interworking between different network types is a middleware service. Service component category B1 Transport of information service components These service components include: transport of data from interface to interface (these interfaces must be of the same network type, but may be of different domains); transport of messaging required by functions in support of service component category B3.
The GII requires telecommunications service components which will transport data, voice and video globally. These are available today from a variety of telecommunications networks including the PSTN, the narrow-band ISDN, the Internet, X.25 data networks, frame relay data networks, CBDS data networks, mobile networks, private voice and data networks, CATV networks, broadcast TV distribution networks, terrestrial and satellite broadcast TV networks, duplex satellite networks including VSAT and LEO satellite networks. However, each of the networks can only in part, meet the overall requirements to transport data, voice and video. The anticipation is that the next generation of telecommunications networks, based on ATM, will be able to offer a more complete set of service components appropriate to the GII. These networks are expected to offer native ATM service components, such as B-ISDN, as well as supporting many of the protocols for the networks identified above. Service component category B2 Processing and storage service components These service components include: mounting, invoking and handling an application component such that it can react and respond to messages from other application components; processing of threads of execution on a processor; storage of data in a memory device, e.g. RAM, hard disk drive, or magnetic tape storage device.
These service components are normally made available through an Application Programming Interface (API). There are currently many API specifications, however, most are publicly available but proprietary. The detailed specification of the API and the service components it offers is normally very complex. This makes standardization by the traditional method of consensus difficult. Some groups have moved towards a technique of simply adopting an existing publicly available standard. These include the APIs of UNIX (owned by X/Open), MS-DOS, Win16, Win32, and ActiveX (owned by Microsoft Corporation), and Java (owned by Sun Microsystems). Service component category B3 Control and management of functions supporting service component categories B1 and B2 These service components include: control of threads of execution on an information appliance; file storage and retrieval operations; connection, call and session control service components;
(06/98)
19
7.3.2
management service components related to basic transport, processing and storage service components. Middleware service components
The middleware part of the GII includes all the capabilities which can combine baseware service components and adds the functionality required to provide the full range of infrastructural service components. Specific middleware service components include the direct mapping of baseware service components and these are not listed again. These baseware service components are also required to support the other middleware service components. These additional middleware service components, which form the main part of the middleware service components, can be categorized in the following service categories. These are the service components offered by the roles of the GII to users of the GII, i.e. structural roles. All of these service components will have commercial aspects including ways in which they can be bought, ways in which usage is defined and monitored, and probably ways in which performance level can be guaranteed. These belong to four categories of service. Service component category M1 GII service packaging and cooperation service components In order to enable the packaging of service components into infrastructural services, a category of service component is required which provides the service components which support the packaging itself. These service components principally are supporting cooperation between different systems. Service component category M2 Middleware support components This is the group of services which has the wide variety of service components which are required by the communication and network of information role in order to supply general GII services and include: human-computer interface service components; registration service components; authentication service components; security service components; directory service components; navigation service components; browsing and searching service components; accounting and billing service components; auditing service components; revenue sharing service components; service management components.
Service component category M3 Application/service creation support The service components supplied by this role enable users to compile and build applications and/or services. More precisely, the service components are normally specific to the platform on which the application/service will run; this includes the service components offered by the main operating roles, i.e. communication and networking of information, telecommunications service provision, and information processing and storage. An important aspect of the service components offered by this role is the ability to create applications/services flexibly by holding components of an application/service and being able to build these together into a specific application/service.
20
(06/98)
Service component category M4 GII interworking service components These are service components dedicated to internetworking and to support distributed applications across information appliances supporting different baseware service components. In addition, this includes the many translation service components which can translate messages and files created in one format into a different format. There are several approaches to the definition of interworking service components. The approach adopted by the Object Management Group (OMG) for interworking between different formats of service definition is the use of a common interface definition language (CORBA IDL) to which all other service definition languages can be translated. A translation from one service definition to another can therefore take place via CORBA IDL. 7.4 Domains and service provisioning platforms
These concepts allow the structural model to take into account commercial aspects of service when a service is offered by one player to another. In addition it allows the structural model to take into account services which require cooperation between more than one player. 7.4.1 Domains and contracts
A service will often be offered across a boundary between two players and the service takes on commercial and contractual aspects. A player may divide the resources which it owns and operates into one or more domains for administrative purposes. These domains are likely to be aligned to the roles identified in the enterprise model and enable service interfaces to any domain to take on commercial and contractual aspects. 7.4.2 Service provisioning platforms
Many services, particularly those requiring network resources, will require resources owned and operated by several players. A service provisioning platform is the collection of all the federated resources required to offer a service. 8 8.1 8.1.1 GII functional model Purpose of the functional model and its terms and definitions Purpose of the functional model
The functional model is an abstract description of a system and is developed in such a way that it is independent of any implementation of the system. Its purpose includes: to allow freedom in methods of implementation without affecting the operation of the overall system; to allow large scale functional integration inside one equipment or software module while retaining a manageable and scaleable description of the equipment or software module; to allow the dynamic creation of services which can be tailored to the needs of clients.
The use of functional models is finding more widespread use in both the telecommunications and information technology industries and there are many examples of functional models and functional modelling methodologies. These include: the information and computational viewpoints of the ODP reference model; the use of Service Independent Building blocks (SIBs) in IN;
(06/98)
21
the layered description of the SDH interface description and the use of functional blocks in the equipment specifications; the extensive use of layers of APIs in operating and software support system architecture.
Figure 8-1 shows the general features of a functional model.
Function Information formats transaction protocol
Function
T1311720-97
Figure 8-1/Y.110 Functional model
8.1.2
Semi-formal definition of terms in the functional model
8.1.2.1 function: A function is a logical entity which carries out a defined task in response to specified inputs and will generate specified outputs. The definition of a function does not imply any particular implementation but does imply any grouping of functions in an implementation (even if, in practice, there may be few alternatives in its implementation). 8.1.2.2 object: In its most abstract terms, an object is a function; however, the two terms have grown up in different environments. Functions tend to be used in the telecommunications environment where they are often implemented directly in hardware, while objects have grown up in the software environment. While strictly they can be regarded as synonymous, the two terms will often be used to reflect this practical distinction. 8.1.2.3 logical interface, protocol and functional reference point: A logical interface is the full specification of the interactions between two functions including the format of information passed between the two functions and the computational aspects of each function which determine the response of a function when information is passed to it from the other function. A protocol and a functional reference point are both logical interfaces. The term "protocol" has grown up in the transactional messaging environment while the term "functional reference point" has grown up in the telecommunications environment. These terms are used in these contexts but are still logical interfaces. 8.1.2.4 information format: The information format describes the way in which messages and other data are encoded in a protocol. This can include information interface definition languages such as CORBA IDL, Internet protocol formats such as HyperText Markup Language (HTML), signalling message formats, voice and video coding schemes, and multiplexing schemes such as ATM and SDH. 8.1.2.5 computation: The computation of a function describes the way in which the function reacts to information which is passed to it. The computation will record the internal state of the function so that when a piece of information is received, a predictable response can be specified. An example of computation specifications in the telecommunications environment are signalling SDL diagrams. 8.1.2.6 object interface: An object interface is similar to a protocol and functional reference point; however, it is specified from the viewpoint of only one object (or function). In this manner, the way in which any other object (or function) interacts with the object (or function) can be specified once only. Once an object (or function) interface has been specified, it can be publicly declared so that many other objects (or functions) can be designed to be able to interact with it.
22
(06/98)
8.1.2.7 segment: A segment is the entity which is common to the enterprise modelling, the structural modelling, and the functional modelling. A segment is part of one role, owned and operated by one player, part of one (and only one) service provisioning platform, and part of one domain, and is composed of a well-defined set of functions. 8.2 Impact of distributed applications on the functional model Locally bounded applications: applications that can be invoked, handled and run completely within one information appliance and do not require any communications services (e.g. editing of a word processor document on a stand-alone PC); Distributed applications: applications which have several components which are running on different information appliances and therefore require cooperation between the information appliances (e.g. cooperative editing of a large publication by many people of several sites).
It is possible to define two types of applications:
The applications can be broken down into segments and it is possible to define a number of types of segments: Segments of a locally bounded application: components of a locally bounded application, which, by definition, are running on the local information appliance (e.g. the components of a word processor which open, close and save document files to and from a local storage device); Local segments of a distributed application: components of a distributed application which run on the local information appliance, (e.g. the components of a word processor which open, close and save document files to and from a remote storage device); Remote segments of a distributed application: components of a distributed application which run on remote information appliances or run on a platform which is supporting the provision of communications services between information appliances (e.g. the file server component on a remote information appliance which responds to the requests for remote file operations in response to local requests to open, close, and save, word processor document files).
These define different types of application components which, in the functional model, are collections of application functions. In addition, middleware functionality can be distributed in the same way as applications leading to different types of middleware components which are collections of middleware functions. 8.3 Domains and service provisioning platforms
Segments are the basic unit that can be seen in all four models. Each model shows different aspects of segments: The enterprise model defines the purpose of the segment in a value chain. The structural model defines the service components supplied by the segment which can contribute to services. The functional model defines the functions within a segment. The implementational model defines the external interfaces to the segment.
In addition, a segment will belong to only one domain of a network operator and form part of only one service provisioning platform. The relationship between segments, domains, players, and service provisioning platforms is illustrated in Figure 8-2. This shows that any one domain is part of only one service provisioning platform and is owned and operated by only one player; however, it can contain more than one
(06/98)
23
segment. A service provisioning platform will normally contain several domains often owned and operated by different players.
Segment Player 1 Domain
SPP level
SPP Segment level SPP level of co-operation
SPP level Domain level Player 2

T1314960-98
Figure 8-2/Y.110 Relationships between segments, domains and service provisioning platforms
8.4 8.4.1
Functions and logical interfaces in the GII Types of functions and logical interfaces
In order to produce a description of the GII which is independent of implementation, it is necessary to describe the functions in the GII and the logical interfaces between them. The following are the basic types of functions in the GII: Applications Functions (AF) The logical entities of applications (these are usually implemented in software and are normally called application objects). Middleware Functions (MF) The logical entities of middleware (these are also usually implemented in software and are normally called middleware objects). Service Control Functions (SCF) These are the middleware functions which are the logical entities which allow the building of services from service components and the associated resources and control the interaction of the user with the service (these functions are sometimes associated with session control as is the case in DAVIC architecture). Management Functions (ManF) These are the middleware functions which are the logical entities which do the management of all the other functions.
Baseware Functions (BF) The logical entities which allow application and middleware functions to run, communicate with other functions by interfacing with network functions, and interface to users (these functions are normally associated with operating systems or virtual machines such as a JAVA virtual machine).
24
(06/98)
Network Functions (NF) These are the baseware functions which are the logical entities which support communication between separated locations in the GII and include Transport Functions (TF) and Control Functions (CF). Processing and Storage Functions (P&SF) These are the baseware functions which are the logical entities which execute middleware and application components and store information. Human-Computer Interfacing Functions (HCIF) These are the baseware functions which are the logical entities which allow application components to present information to a human user and gain input from a human user.
Each of these can be further subdivided. Subdivisions of network functions are described in 8.5. In the course of time, many application functions become reusable by other new applications and then are able to migrate to middleware functions. It is this migration which supports the evolution of infrastructural services described in 7.2. There are also a number of types of logical interfaces which are associated with logical interfacing between different types of functions. These are: Application Protocol (AP) a logical interface between application functions; Application Programming Interface (API) a logical interface between application functions and the middleware functions which support the application functions (baseware functions may also be transparently mapped from the BPI to be available at the API); Middleware Protocol (MP) a logical interface between middleware functions; Basic Programming Interface (BPI) a logical interface between middleware functions and baseware functions supports the middleware functions (basic programming interfaces are often called application programming interfaces which reflects the evolution and growth of middleware functionality); Human-Computer Interface (HCI) the logical interface between the human user and, principally, baseware functions; however, it can also include the logical interface between the middleware functions or even applications functions; Telecommunications Reference Point (TRP) the logical interface between baseware functions and network functions or between network functions. Functions and roles
8.4.2
Figure 8-3 illustrates the basic types of functions and the basic types of logical interfaces in the GII and their likely relationship to roles. The relationship between functions and the role of the enterprise model for which they perform their function is determined by the needs of the role. For example, a communication and networking of information role will require many middleware functions in order to have the resources to be able to offer the range of service components associated with this role. However, while a generic communications role will need to have many network functions in order to be able to offer the service components associated with the role, it may also have some middleware functions in order to provide a slightly wider range of services. In this way, the description of each role has some flexibility and there may be an overlap in the functionality between different roles.
(06/98)
25
Structural role
Communication and networking of information Distributed information processing and storage service provision
Application Programming Interface
Application functions
Middleware functions Basic Programming Interface Baseware functions Control functions Transport functions Control functions Generic communications service provision
Humancomputer interfacing functions
Processing and storage functions
Transport functions
T1311740-97
Figure 8-3/Y.110 Types of functions and their relationship to roles
Figure 8-4 shows an example of functions interconnected across different distributed locations and the logical interfaces associated with these functions.
Application protocol Application functions Application functions API
Middleware functions
Application protocol Application functions Middleware protocol

Middleware protocol BPI

Baseware functions Control functions Transport functions
API
BPI
Baseware functions
BPI
Baseware functions
CF HCIF P&SF
Control functions Transport functions
CF
CF
CF
CF
TF
TF TRP
P&SF TF TRP
TF TRP
P&SF TF
T1311750-97
HCI
TRP
Figure 8-4/Y.110 Example of distribution and logical interfaces
8.5
Network functions and the network operator's domain
A telecommunications network will generally require at least transport functions and control functions as well as management functions. In addition, a telecommunications network can have additional functions which support enhanced services such as those associated with IN capabilities. A network operators domain is therefore likely to have: transport functions entities enabling the transport of information between distant locations; control functions entities enabling information to be successfully routed between the desired end points as well as base service control functions;
26
(06/98)
enhanced service provisioning functions entities enabling enhanced services associated with IN to be provided and controlled; management functions entities required to manage the other functions in the network operator's domain.
Figure 8-5 shows an example of communications between two sets of applications supporting functions (i.e. middleware and baseware functions) through two cooperating network operators' domains. The logical interfaces between the functions, in this case reference points, are also illustrated.
RP
Management Functions (ManF) (see Note) RP
ManF RP RP BF & MF RP RP RP Service Providers Domain (SPD) RP
Baseware & Middleware Functions (BF & MF) Customers Domain (CD)
RP RP
Enhanced Service Control Functions (E-SCF) (see Note) RP Transport and Control Functions (T&CF) Network Operators Domain (NOD)
E-SCF RP
T&CF RP NOD RP
T1311760-97
RP
NOTE These functions include the appropriate middleware functions.
Figure 8-5/Y.110 Example of network functions in two network operators' domains
These functions can be further subdivided into segments. For example, the transport and control functions can be divided between core segments and access segments as illustrated in Figure 8-6. Functions in a segment would normally be implemented together so that any reference points within a segment would be a low priority for standardization, while those between segments especially when the segments are in different network operators' domains would be a higher priority for standardization. In addition, the segment provides a link between the functional model and the implementational model.
(06/98)
27
Management Functions (ManF) RP RP RP RP Enhanced Service Control Functions (E-SCF) RP RP BF&MF BF&MF RP RP access segment access segment RP core segment RP RP RP
ManF RP RP
ManF
RP
E-SCF RP RP RP RP RP
core segment RP T&CF NOD
access segment RP T&CF NOD
BF&MF
RP Transport and Control Functions (T&CF) Network Operators Domain (NOD)
T1311770-97
Figure 8-6/Y.110 Example of segments in a network operator's domain
8.6
Transparency of middleware and application protocols
Figure 8-7 shows an example of functions which are interconnected with logical interfaces, the different types of logical interfaces being highlighted.
10 Management functions Management functions
5
Middleware and baseware functions Middleware and baseware functions
5 Service Control functions
Control functions 4 2
Transport functions
Transport functions
1
Middleware and baseware functions
7
Middleware and baseware functions
T1311780-97
People
Figure 8-7/Y.110 Example of functions and logical interfaces
28
(06/98)
The different highlighted logical interfaces have the following properties: 1, 9 transport telecommunications reference points which can transparently support other logical interfaces including application protocols, middleware protocols, and even the control protocol between the base functions and the network control functions; a transport telecommunications reference point which enables the network control functions to communicate with baseware functions, other network control functions and service control functions; a transport telecommunications reference point between transport network functions which should support all types of protocols transparently; a network control reference point between baseware functions and network control functions which enables other communications services to be established, but is itself, carried transparently by the transport functions; management reference points There are many examples of management reference points and where there is geographical separation, they must be carried transparently by transport functions; management protocol Communications between management functions.
3 4
6, 7, 8 middleware protocols which must be carried transparently by the network functions; 10 The transparency between middleware protocols and the network functions supporting them is enabled by the basic programming interface while the transparency of application protocols is enabled by the applications programming interface. This transparency is an essential feature of the GII and allows middleware and applications to be developed in independence from the supporting infrastructure. 9 9.1 9.1.1 GII implementational model Purpose of the implementational model and its terms and definitions Purpose of the implementational model
Generally, formal standardization would end with a functional model as this should be sufficient to guarantee interoperability between operator and equipment/software vendors. There are, however, occasions when it is important to develop an implementational model which describes how the functions of the functional model are implemented in equipment owned by operators. Reasons for developing an implementational model could include: differentiating and characterizing those interfaces which are important for standardization for example interfaces between operators and interfaces between equipment from different vendors thereby enabling priority to be given to the standardization of the interfaces; a set of examples to illustrate how system performance can be affected by implementation.
An implementational model shows which functions are implemented in which equipment. It also identifies all the protocols which are passing across an interface between equipments. This is illustrated in Figure 9-1.
(06/98)
29
F F F Interface F F F F F
Equipment
Equipment
T1311790-97
Figure 9-1/Y.110 Implementational model
9.1.2
Semi-formal definition of implementational modelling terms
9.1.2.1 equipment: An equipment is an implementation of one or more functions in a single physical container. It will have at least one function implemented in hardware and will have physical interfaces through which it can be connected to other equipments. It may be designed in a modular way in that the equipment can be made up from a number of smaller pieces of equipment, such as plug-in cards, thus enabling the customization of the exact composition of functions that are implemented in the equipment. In addition, it may have some functions implemented in software which can be changed during the lifetime of the equipment. 9.1.2.2 software module: A software module is an implementation of one or more functions exclusively by software. A software module must run on an equipment and interfaces to the equipment across an Application Programming Interface (API). 9.1.2.3 information appliance: An information appliance is a particular type of equipment which is designed for use in the GII. It is capable of accessing and/or hosting the software modules which provide the functionality of the structural roles of the GII. 9.1.2.4 implementational interface: An implementational interface is an interface between components in an implementation, i.e. between equipments or between an equipment and a software module. While it is possible to consider an implementation interface between software modules, because of the nature of software, a good implementation should not require any further specification of this interface over and above the protocol specification of the functional module and the API definitions. All aspects relating to the way in which the protocol is carried should be masked by the API. 9.1.2.5 physical interface: This is an implementational interface between equipments and requires a physical medium to transport the information. 9.1.2.6 application programming interface: This is an implementational interface between an equipment and a software module and does not have any physical realization as it is internal to the equipment. 9.1.2.7 system: A system is a collection of equipments and/or software modules which would normally work together as a single entity. For example, a line system is a system comprising line terminal equipments, regenerator equipments, optic fibre cable "equipments", and management software modules. 9.1.2.8 system segment: A system segment is one or more systems which perform the functions identified in a segment of the functional model.
30
(06/98)
9.2
Segments in the implementational model
The implementation of the GII involves connecting together a number of implementational components. These include the following: information appliances equipments which allow users to gain access to the GII and/or which can mount, invoke and handle software modules including the software modules which are databases and video libraries. Examples include PCs, Set-Top Boxes (STBs), network computers, miniframe and mainframe computers, file and video servers, transaction processors, and in a more restricted way, the telephone, TV and fax machine; middleware software modules software modules which contain middleware functions. Middleware software modules run on information appliances; application software modules software modules which contain application functions. Application software modules run on information appliances; segments of telecommunications networks segments of the telecommunications network which connect together information appliances and allow middleware functions and applications functions which are mounted on different information appliances to communicate with each other. These segments include access segments, core segments, enhanced service provisioning segments and management segments.
Each of these are segments in the implementational module and are interconnected with interfaces. The interfaces between information appliances and access segments of telecommunications network are physical telecommunications interfaces, as are the interfaces between access segments and core segments. Their specification is derived by the process illustrated in Figure 9-1; the physical interface information must also be added. For example, in the interface between an information appliance and an access segment, the logical interface information between the functions in the baseware of the information appliance and the functions in the access segment are combined to form the basic interface specification; the physical interface aspects are also added. Other interfaces are either programming interfaces which are internal to information appliances or protocols which are transparent across the telecommunications networks. These implementational interfaces therefore are not physical interfaces and their specification can be derived directly from the logical interfaces in the functional model by the process illustrated in Figure 9-1, without the addition of any physical interface specification. The nature of information appliances, middleware software modules and application software modules is for further study. The following subclauses describe aspects of segments of telecommunications networks in the GII. As a segment is owned and operated by a single operator and is likely to be implemented with equipment from a single vendor, interfaces within a segment have a lower priority for standardization than those between segments. The inter-segment interfaces are the critical interfaces in the multioperator, multi-vendor environment of the GII. 9.3 Segments in telecommunications networks
Figure 9-2 illustrates information appliances connected by a telecommunications network made up from different segments. These telecommunications network segments the customer network segment(s), access network segment(s), core network segment(s), and international network segment(s) can each be operated by different players and generally interconnected as illustrated in Figure 9-2.
(06/98)
31
In addition, each segment is technology- and implementation-dependent; however, the delivery of a particular service will require a certain set of GII functions to be implemented in each of these segments. This framework of telecommunications network segments provides the common point with the scenario methodology described in Recommendation Y.120. The scenario methodology describes the "bottom-up" way of developing types of segments; this framework allows the segments described in the scenarios to be linked to the enterprise, structural, and functional models. More specifically, the examples in Annex A2 of Recommendation Y.120 describe scenarios with different configurations and types of telecommunications network segments.
Information appliance C T Interface
Customer Network segment control functions transport functions
Access Network segment control functions transport functions Interface Interface
Core Network segment control functions transport functions Interface Interface Core Network segment control functions transport functions Interface Information appliance C T
International segment control functions transport functions Interface Interface International segment control functions transport functions Interface Interface
T1311800-97
Information appliance C T
Access Network segment control functions transport functions Interface
Figure 9-2/Y.110 Example of information appliances connected by telecommunications network segments
Figure 9-2 includes the situation where a number of access segments (or core segments or international segments) are owned and operated by different players in the same locality and are therefore in competition with each other. In this case, the interfaces are points of interconnection between parallel, competitive operators.
NOTE The functional and geographical boundaries of competitive segments may not be precisely the same; this affects the degree to which two segments of the same basic type are competitive and the extent to which they are complementary.
9.3.1
Structuring of implementation possibilities in the example
For each of the generic segments listed, there are a large number of possible implementations and a large number of interfaces can be used to interconnect them. The following is a list of some of the current possibilities.
____________________
2
Presently at the stage of draft. Recommendation Y.110 (06/98)
32
Examples of information appliances: personal computer (PC); Set-Top Box (STB); network computer; mini computer; mainframe computer; file/video server; transaction processor (e.g. SCP); telephone; TV; fax machine. PSTN/ISDN copper access network; xDSL copper access network; cable TV network; direct fibre access network; passive optical network; radio in the loop (RITL) access network; digital mobile access network (e.g. GSM); terrestrial broadcast TV network; direct broadcast satellite network; geostationary-satellite access networks (e.g. Inmarsat); medium- and low-Earth orbit satellite access networks. PSTN/ISDN core network; PSDN core network; X.25 packet network; frame relay network; SMDS network; B-ISDN network; leased line network; Internet. PSTN interface; basic rate and primary rate ISDN interface; Ethernet interfaces; token ring interface; B-ISDN interfaces; DVB satellite air interface;
Examples of access segments:
Examples of core segments:
Examples of information appliance to access segment interfaces:
(06/98)
33
GSM mobile air interface; geostationary-satellite access network air interface; medium- and low-Earth orbit satellite network air interfaces.
Some examples are selected in the following subclauses to demonstrate how implementation examples can be constructed based on these segments. The examples concentrate mainly on information appliance, the access segment and the interface between them. 9.3.2 Information appliance configurations
The configuration shown in Figure 9-3 is related to the information appliances of an end user in the residential environment. The configuration contains a combination of a fixed analogue phone, a cordless telephone, a fax machine, a PC and a STB connected to an analogue TV. The applications are assumed to require GII capabilities including voice telephony, data transport and interactive multimedia capabilities. The following two alternative solutions illustrate how such an end user might configure their information appliances for connection to an access segment (terminated with an NTU in these examples). In the first example all the information appliances are connected to the access segment through the STB. In the second example, there are separate interfaces for the phone/fax, the PC and STB/TV.
Customer domain
Customer domain
TV TV Phone
STB Phone
STB
NTU
Fax Fax BS
NTU
cordless Mobile phone CTI
PC
cordless Mobile phone CTI
PC
T1311810-97
Figure 9-3/Y.110 Examples of a residential end user's information appliances
The Network Termination Unit (NTU) is part of the access segment; depending on the network implementation, the end users information appliances can be supported via one or more access segments. In the example, the TV could be connected via a cable TV network while the phone, the fax machine, and the PC could be connected via an ISDN 2B+D access. In this case there would be no backward channel in the cable TV network; thus, interactivity would be achieved via the ISDN access.
34
(06/98)
9.3.3
Access segment configurations
There are a large number of access segment configurations which are possible; these will depend largely on the technology used, governed primarily by the physical media. This could be copper pair, coax, fibre, terrestrial radio or satellite. While many access segments are implemented with only one physical media, other access segments will use a combination of these media. 9.3.3.1 Fixed network access segment configuration
A fixed network access segment is built mainly on copper pairs and a combination of copper and fibre. In certain areas, however, radio in the loop might be used. The configuration of such an access segment is illustrated in Figure 9-4.
Access segment NTU NTU NTU NTU xDSL NTU NTU NTU Access adaptor xDSL xDSL Access adaptor Access adaptor FTTB/C FTTH Access adaptor FTTB/C radio Access adaptor fibre (ATM/SDH) fibre (ATM/SDH) fibre (ATM/SDH) fibre (ATM/PON)
copper Multi service access unit V5.x
Vb5.x
T1311820-97
Figure 9-4/Y.110 A fixed network access segment configuration
9.3.3.2
Cable TV network access segment configuration
A cable TV network solution is often built on Hybrid Fibre-Coax (HFC) technology. It is anticipated that when such technology supports digital TV, e.g. DVB, there will be at least one channel available for interactive services and will also support voice telephony. Interactive services and voice telephony are terminated at the head end. Such a configuration is illustrated in Figure 9-5.
Access segment Coax Access adaptor
fibre
upstream channel downstream channel Head End
Phone/Data services TV/Video services

T1311830-97
Figure 9-5/Y.110 A cable TV access segment configuration
(06/98)
35
9.3.4
Variety of telecommunications network segments and their interconnection
Figure 9-6 illustrates a number of the possible types of core network segments and access network segments along with a number of different customer domains (some with a customer network segment, some only with information appliances). In considering the implementational model, it is essential to describe comprehensive network configurations and components to be studied in the GII. Based on this, it is important to clarify the nature of important inter-equipment and inter-operator interfaces. Types of core network segments include telecommunications networks such as PSTN, N-ISDN, and B-ISDN, and client layer networks such as Internet, which may utilize telecommunications network as a backbone. Types of access network segments include the local parts of telecommunications networks such as PSTN and N-ISDN, as well as CATV networks, xDSL networks, mobile networks, and satellite networks. These use various kinds of physical media such as copper, fibre, coax/HFC, and wireless. Customer premises network includes business premises network, where some kinds of information appliances such as telephone, TV and PC are interconnected via wired or wireless LAN, and residential premises network, where such information appliances are interconnected via access unit. Various kinds of network services would be provided by means of such network segments. Some other components such as video servers, head ends, and routers might be necessary for specific services. As the network configurations and components listed above are defined as segments in the implementational model, interface points are specified between each segment. Therefore, the important interfaces are clarified between various kinds of network configurations and interconnections of the components.
36
(06/98)
Satellite Information provider A Video server * The Internet to * BS RLL, terrestrial broadcast (Wireless)
Phone TV PC # Customer access unit
Phone TV PC Customer access unit
Gateway router BS Internet provider Backbone Edge (N-ISDN/B-ISDN/ Edge router router Leased line) Information provider B Video server Switch/ SLT Mobile (Wireless)
Mobile handsets
to # B-ISDN (Fibre(PON))
to # LAN Phone TV PC
Router CS CATV (Coax/HFC) Wireless LAN Business building
Edge Router
Telecommunications network A (B-ISDN) Switch Switch
to *
Head end
to # to #
Phone ADSL (Copper) N-ISDN/PSTN/ Leased line (Copper/Fibre) TV PC Customer access unit Residential home
to * Telecommunications network B (N-ISDN/PSTN/ Leased line) Switch/ Switch/ Transmission Transmission system system
Head end
Switch/ SLT
Access node Core network Access network
Customer domain
T1311840-97
Network Terminating Unit SLT Subscriber Line Termination ADSL Asymetrical Digital Subscriber Line
Figure 9-6/Y.110 Examples of configuration between different types of telecommunications segments
(06/98)
37
APPENDIX I The relationship of socio-economic issues to standards This Appendix describes the scope and involvement of the ITU on the role of two configuration parts (socio-economic and industry part) of the Society Infrastructure and focusing area of ITU on making recommendations on the GII based on technical viewpoints rather than on socio-economic points on GII. I.1 The configuration of information society and its role
A society consists of a socio-economic part and an industry part with respective specific roles that are shown in Figure I.1. That is, the information society operates upon the roles of and between these two parts. The roles of these two parts in information society are summarized below: Socio-economic part: establishing life-styles, courtesy and customs (e.g. teleshopping-shopping life, etiquette for virtual society, etc.); creating cultures and arts (e.g. multimedia books, tele-orchestration, etc.); building regulations, laws and provisions (e.g. medical law in telemedicine, etc.); creating applications and services (e.g. teleshopping-shopping, video services, etc.); building information networks (e.g. telecommunication networks, CATV, satellites, etc.); manufacturing facilities (e.g. terminals, transmission systems and DBMS, etc.).
Culture/ Life-style Socio-economic part Regulations/ Laws Common understanding of global cultures Develop regulation/law environments for global economy National matters WTO, others
Industry part:
Application/ Service Industry part Network/ Facilities
Make consensus & develop global applications/services Develop international standards
Standard body, Consortia, etc.

T1311850-97
WTO World Trade Organization
Figure I.1/Y.110 The configuration of GII and the role of each part
38
(06/98)
I.2
ITU involvement in the GII
To make a Global Information Society, many organizations and parties shall be involved and cooperate with each other. Based on this, Figure I.2 summarizes the involvement of the ITU in the GII.
Socio-economic of GII Out of scope of ITU-T/R
General understanding on GII
l l l
Value added chains Enterprise models etc.
Terms and references Work programme Principles & frameworks Bridge Scenarios
Scope of ITU
T1311860-97
Figure I.2/Y.110 Summary of ITU activities in the GII
(06/98)
39
ITU-T RECOMMENDATIONS SERIES

Series A Series B Series C Series D Series E Series F Series G Series H Series I Series J Series K Series L Series M Series N Series O Series P Series Q Series R Series S Series T Series U Series V Series X Series Y Series Z Organization of the work of the ITU-T Means of expression: definitions, symbols, classification General telecommunication statistics General tariff principles Overall network operation, telephone service, service operation and human factors Non-telephone telecommunication services Transmission systems and media, digital systems and networks Audiovisual and multimedia systems Integrated services digital network Transmission of television, sound programme and other multimedia signals Protection against interference Construction, installation and protection of cables and other elements of outside plant TMN and network maintenance: international transmission systems, telephone circuits, telegraphy, facsimile and leased circuits Maintenance: international sound programme and television transmission circuits Specifications of measuring equipment Telephone transmission quality, telephone installations, local line networks Switching and signalling Telegraph transmission Telegraph services terminal equipment Terminals for telematic services Telegraph switching Data communication over the telephone network Data networks and open system communications Global information infrastructure Programming languages

T Rec Y.110 199806 I!!pdf e

Uploaded by

Copyright:

Available Formats

T Rec Y.110 199806 I!!pdf e

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

T Rec Y.110 199806 I!!pdf e

Uploaded by

Copyright:

Available Formats

INTERNATIONAL TELECOMMUNICATION UNION

SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE General

Global Information Infrastructure principles and framework architecture

ITU-T Recommendation Y.110

ITU-T Y-SERIES RECOMMENDATIONS GLOBAL INFORMATION INFRASTRUCTURE

Y.100Y.199 Y.200Y.299 Y.300Y.399 Y.400Y.499 Y.500Y.599 Y.600Y.699 Y.700Y.799

For further details, please refer to ITU-T List of Recommendations.

Concepts in the simple enterprise model....................................................................

Features of relationships between roles......................................................................

Structure of services and applications ........................................................................ 7.2.1 7.2.2 7.2.3

Infrastructural service components............................................................................. 7.3.1 7.3.2

Domains and service provisioning platforms............................................................. 7.4.1 7.4.2

8.5 8.6 9 9.1

For further study. 4 Objective and principles of the GII

These principles will apply to the GII by means of: 5

Telecommunication AIM Computer/ Information

GII Telecommunication Consumer/ Entertainment

Figure 5-1/Y.110 GII is at the centre of the threefold industrial convergence

Features of the users' viewpoint of the GII

End users perspective

Telecommunications industrys perspective

Information technology industrys perspective

Standards bodies perspective

Broadcast entertainment industrys perspective

Figure 5-2/Y.110 Examples of viewpoints on the GII

communication networks and services

communication networks and services

Private networks B-ISDN ISDN information appliance

other network types information appliance

inform a applia tion nce

These basic elements interact as illustrated in Figure 5-5.

Information Application support platform Communications support platform Information appliance

Information Application support platform Communications support platform Information appliance

Figure 5-5/Y.110 Conceptual overview of the GII and its users

goods or service consumed by end user

intermediate goods or service

intermediate goods or service

intermediate goods or service

Figure 6-1/Y.110 Enterprise model

Global Information Infrastructure

EUR PISR PICR IOR

Figure 6-2/Y.110 Structural roles as the users of the GII

Terminal equipment supply

Communication and networking of information

Application/ service creation support

Generic communications service provision

Distributed information processing and storage service provision

Figure 6-3/Y.110 Infrastructural roles within the GII

Features of relationships between roles General features of relationships between roles

Global Information Infrastructure

Figure 6-4/Y.110 Structural roles as the users of the GII

customer aspect of structural role

supplier aspect of structural role

Figure 6-5/Y.110 The relationship between roles

Scope of structural role of the GII

News on demand Voice information (Message) Application

Navigator, Remote Controller

Application support function Service

Application support function Service Service support function