ETSI TR 101 984 V1.2.1 (2007-12) Technical Report

TR 101 984 V1.2.1 (2007-12) Technical Report Earth Stations and Systems (SES); Broadband Multimedia (BSM); Services and architectures

2 TR 101 984 V1.2.1 (2007-12) Reference RTR/SES-00274 Keywords architecture, broadband, IP, multimedia, satellite 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRACE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret 348 623 562 00017 - AF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) 7803/88 Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on printers of the PDF version kept on a specific drive within Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other documents is available at http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http://portal.etsi.org/chaircor/_support.asp Copyright otification o part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2007. All rights reserved. DECT TM, PLUGTES TM and UMTS TM are Trade Marks of registered for the benefit of its Members. TIPHO TM and the TIPHO logo are Trade Marks currently being registered by for the benefit of its Members. 3GPP TM is a Trade Mark of registered for the benefit of its Members and of the 3GPP Organizational Partners.

3 TR 101 984 V1.2.1 (2007-12) Contents Intellectual Property Rights...5 Foreword...5 Introduction...5 1 Scope...6 2 References...6 2.1 Informative references...6 3 Definitions and abbreviations...7 3.1 Definitions...7 3.2 Abbreviations...9 4 Overview of BSM...10 4.1 scenarios...10 4.2 IP ing scenarios...11 5 BSM roles, actors and equipment...12 5.1 General...12 5.2 Roles...12 5.2.1 Definitions...12 5.2.2 Relationships between roles...13 5.3 Equipment...14 5.3.1 Definitions...14 5.3.2 Relationship between roles and equipment...14 5.4 Billing and usage relationships...15 6 BSM reference models and architectures...16 6.1 Definitions...16 6.1.1 BSM System; etwork and Sub...16 6.1.2 Transparent and regenerative satellite architecture...17 6.1.3 Topologies...18 6.1.4 Link and channel attributes...18 6.2 BSM etwork Types...19 6.2.1 aming conventions...19 6.2.2 Transparent Star (TSS)...20 6.2.3 Transparent Mesh (TSM)...21 6.2.4 Regenerative Mesh (RSM)...22 6.3 Reference models...23 6.3.1 Reference models for access scenario...23 6.3.1.1 U-plane reference model...23 6.3.1.2 C-plane and M-plane reference model...24 6.3.2 Generalized reference models...25 6.3.2.1 BSM types...25 6.3.2.2 Other BSM scenarios...25 6.4 Protocol architecture...26 6.4.1 BSM protocol architecture...26 6.4.2 SI-SAP and BSM families...27 6.4.3 Independent Service Access Point (SI-SAP)...27 6.4.4 BSM bearer services layered architecture...28 6.4.5 Air interface lower layer service elements...29 7 General service definitions...31 7.1 Media components...31 7.2 BSM connections...31 7.3 BSM service capabilities...31 7.4 Interoperability...32 8 Bearer services...32

4 TR 101 984 V1.2.1 (2007-12) 8.1 Definitions...32 8.1.1 Telecommunications bearer services...32 8.1.2 Connectionless and connection-oriented bearer services...33 8.1.3 Unidirectional and bidirectional bearer services...33 8.1.4 Bearer service symmetry...33 8.1.5 Bearer service configurations...33 8.2 BSM bearer services...34 8.2.1 General...34 8.2.2 Queue Identifiers (QIDs)...34 Annex A: Example protocol models...35 A.1 A protocol model for regenerative satellites...35 A.2 A protocol model for transparent satellites...35 Annex B: Annex C: Topology examples...36 etwork interface examples...37 Annex D: Bibliography...38 History...39

5 TR 101 984 V1.2.1 (2007-12) Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to. The information pertaining to these essential IPRs, if any, is publicly available for members and non-members, and can be found in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to in respect of standards", which is available from the Secretariat. Latest updates are available on the Web server (http://webapp.etsi.org/ipr/home.asp). Pursuant to the IPR Policy, no investigation, including IPR searches, has been carried out by. o guarantee can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Report (TR) has been produced by Technical Committee Earth Stations and Systems (SES). Introduction The present document has been prepared by the TC-SES Broadband Multimedia (BSM) working group based on the recommendations from the work of F-126 [1].

6 TR 101 984 V1.2.1 (2007-12) 1 Scope The present document defines the BSM services and architectures. It contains a set of definitions and reference models in the following main areas: BSM roles and actors; BSM reference architectures and models; BSM bearer services. The present document is intended to define the possible roles that Broadband Multimedia systems may have, to define the main actors, to define a set of reference architectures and to define the services they can provide. These definitions are intended as a common set of definitions for BSM standardization. The overall objectives of BSM standardization are: to enable users to access a wide range of telecommunications services, including many that are today undefined, with particular emphasis on IP-based multi-media services and high data rates; to provide an efficient means of using satellite resources (particularly radio spectrum); to facilitate the provision of a high quality of service similar to that provided by fixed s; to facilitate the provision of easy to use, low cost terminals. 2 References References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. on-specific reference may be made only to a complete document or a part thereof and only in the following cases: - if it is accepted that it will be possible to use all future changes of the referenced document for the purposes of the referring document; - for informative references. Referenced documents which are not found to be publicly available in the expected location might be found at http://docbox.etsi.org/reference. For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the method of access to the referenced document and the full address, with the same punctuation and use of upper case and lower case letters. OTE: While any hyperlinks included in this clause were valid at the time of publication cannot guarantee their long term validity. 2.1 Informative references [1] TR 101 374-2: " Earth Stations and Systems (SES); Broadband satellite multimedia; Part 2: Scenario for standardization". [2] TS 122 101: "Universal Mobile Telecommunications System (UMTS); Service aspects; Service principles (3GPP TS 22.101 Release 7)".

7 TR 101 984 V1.2.1 (2007-12) [3] MFA Forum: "Technology: ATM Forum Specifications". OTE: Available at http://www.mfaforum.org/tech/atm_specs.shtml. [4] TS 123 107: "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Quality of Service (QoS) concept and architecture (3GPP TS 23.107 version 6.4.0 Release 6)". [5] TR 101 865: " Earth Stations and Systems (SES); component of UMTS/IMT-2000; General aspects and principles". [6] TR 102 353: " Earth Stations and Systems (SES); Broadband Multimedia (BSM); Guidelines for the Independent Service Access Point (SI-SAP);". [7] TS 102 357: " Earth Stations and Systems (SES); Broadband Multimedia (BSM); Common Air interface specification; Independent Service Access Point SI-SAP". [8] TS 102 295: " Earth Stations and Systems (SES); Broadband Multimedia (BSM) services and architectures; BSM Traffic Classes". [9] TR 102 187: " Earth Stations and Systems (SES); Broadband Multimedia; Overview of BSM families". 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: broadcast: communication capability which denotes unidirectional distribution to an unspecified number of access points connected to the OTE: The communication may reach any or all access points and each terminal may select which broadcast information to receive. BSM bearer service: user plane (U-plane) data transmission services provided by the BSM sub at the SI-SAP interfaces. OTE 1: A BSM bearer service includes all QoS and other bearer service properties, as viewed at those SI-SAP interfaces. OTE 2: BSM bearer services are a specific form of layer 2 service access point services. BSM bearer services are therefore not the same as a Telecommunications bearer service as defined below. BSM etwork: a BSM sub together with the BSM interworking and adaptation functions that are required to provide an interface into the attached s BSM Sub: all the BSM elements below the Independent Service Access Point (SI-SAP) BSM System (BSMS): A BSM System corresponds to a BSM etwork together with the MC and CC plus any additional elements that are required to provide the services to the subscribers and their users. channel: means of unidirectional transmission of signals between two points OTE: Channel is a generic term that can be used at different layers of the interface (e.g. physical channel, logical channel). Several channels may share a common transport mechanism. connection oriented: communication method in which communication proceeds through three well-defined phases: connection establishment, data transfer, connection release connectionless: communication method which allows the transfer of information between users without the need for connection establishment procedures

8 TR 101 984 V1.2.1 (2007-12) control plane (C-plane): plane which has a layered structure and performs control functions for the various services OTE: The C-plane deals with the signalling necessary to set up, maintain and release bearer services. gateway (GW): element that provides interworking between the BSM and one or more external s. layer management functions: management functions (e.g. meta-signalling) relating to resources and parameters residing in its protocol entities link: capability to exchange data between two points OTE 1: Link is a generic term that can be used at different layers of the interface. For example: data link: capability of the data link layer to exchange data; and physical link: capability of the physical layer to exchange data. OTE 2: Physical link (radio link) names can be used to indicate the direction and/or the usage and/or the operating band. For example, "uplink", "feeder link" or "Ku-band link". management plane (M-plane): plane which provides two types of functions, namely layer management functions and management functions multicast: communication capability which denotes unidirectional distribution from a single ingress service access point to a number of specified egress service access points multipoint: communication configuration attribute which denotes that the communication involves more than two service access points etwork Control Centre (CC): equipment that provides the central control functions for a satellite. etwork Management Centre (MC): equipment that provides the central management functions for a satellite. Independent Service Access Point (SI-SAP): the interface between the satellite dependent lower layers and the satellite independent upper layers of the Terminal air interface Terminal (): element that contains at least one satellite interface. OTE: An normally contains at least one other interface and two different types of can be defined: User : that provides interworking between the satellite and a premises. Gateway : that provides interworking between the satellite and an external. service attribute: specified characteristic of a telecommunication service OTE: The value(s) assigned to one or more service attributes may be used to distinguish that telecommunication service from others. telecommunication service: service offered by a operator or service provider to its customers in order to satisfy a specific telecommunication requirement OTE: Telecommunication services are divided into two broad families: bearer services and teleservices: telecommunications bearer service: type of telecommunication service that provides the capability of transmission of signals between user access points, typically the user- interface (UI); teleservice: type of telecommunication service that provides the complete capability, including terminal equipment functions, for communication between users according to standardized protocols and transmission capabilities established by agreement between operators traffic class (or service class): service offered to the users described by a set of performance parameters and their specified values, limits or ranges OTE: The set of parameters provides a comprehensive description of the service capability. user plane (U-plane): plane which has a layered structure and provides for user data transfer

9 TR 101 984 V1.2.1 (2007-12) 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: ASP Application Service Provider AESA ATM End System Addresses ATM Asynchronous Transfer Mode BSM Broadband Multimedia BSMS Broadband Multimedia System CP Customer CPE Customer Equipment DAMA Demand Assigned Multiple Access Diffserv Differentiated services DL DownLink DLL Data Link Layer DVB-RCS Digital Video Broadcast-Return Channel by DVB-S Digital Video Broadcast by GSM Global System for Mobile communication GW GateWay IB InBound ID IDentifier IETF Internet Engineering Task Force Intserv Integrated services IP Internet Protocol IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 ISD Integrated Services Digital etwork ISP Internet Service Provider ITSP Internet Telephony Service Provider IWF InterWorking Functions LA Local Area etwork MAC Medium Access Control MM MultiMedia MSP Multimedia Service Provider MTM Multipoint-To Multipoint AP etwork Access Provider CC etwork Control Centre MC etwork Management Centre OC etwork Operations Centre SP etwork Service Provider OB OutBound OBP On Board Processing OSI Open System Interconnection PHY PHYsical PILC Performance Implications of Link Characteristics P Public Switched Telephone etwork QID Queue IDentifier QoS Quality of Service RSVP Resource reservation Protocol SAT SATellite SCC Control Centre SD Dependent SDAF Dependent Adaptation Function SI Independent SIAF Independent Adaptation Function SI-SAP Independent Service Access Point SLA Service Level Agreements SLC Link Control SMAC Medium Access Control SME Small to Medium sized Enterprises SO etwork Operator

10 TR 101 984 V1.2.1 (2007-12) SO SP SPHY TCP TM/TC TOS UDP UL UMTS UT VCI VPI VP VSAT EH TSS TSM Operator Service Provider PHYsical Terminal Transmission Control Protocol TeleMetry/TeleCommand Type Of Service User Datagram Protocol UpLink Universal Mobile Telecommunication System User Terminal Virtual Connection Identifier Virtual Path Identifier Virtual Private etwork Very Small Aperture Terminal (satellite) End Host Transparent Star Transparent Mesh 4 Overview of BSM 4.1 scenarios For the present document, we divide the BSM satellite s into 3 different scenarios: Core, Distribution and Access as illustrated in figure 4.1: Access, providing services to end users. Distribution, providing content distribution to the edge. Core, providing trunk interconnect services. Access etw ork (End User <->Edge) Content Distribution to the Edge Core etwork (Trunk Interconnect) Point to point + Multicast Multicast Point to point e.g. ISP links between continents PoP Content Core etwork LMDS, ADSL Figure 4.1: Core, distribution and access Telecommunication satellites can be used to provide broadcasting and multicasting services as well as point-to-point services as illustrated in figure 4.1. In addition to international or long haul communications, figure 4.1 shows satellites being used to provide regional backbone s and access s, including access to added value services such as Internet applications. Due to their natural coverage of large mass of land or ocean satellites are also used to deliver broadcast broadband services such as Digital Video and in this case interactivity can be provided either by the satellite or though a terrestrial telecommunication infrastructure (e.g. P, ISD and GSM).

11 TR 101 984 V1.2.1 (2007-12) 4.2 IP ing scenarios In the global Internet, a BSM system (BSMS) acts as another IP sub. Only a small percentage of IP hosts will be directly connected to that BSMS and it is unrealistic to require that any IP host (including both end hosts and intermediate hosts such as routers) whose traffic transits a BSMS (at some point) should modify its IP-layer protocols. Consequently, the main guideline for interworking IP services over a BSMS is that on the external (non-satellite) side of a Terminal () all IETF internet protocols should be supported unchanged. On the satellite side of an the IP layer protocols can, when applicable, be adapted to better respond to the specifics of the BSMS to accommodate a combination of the following differences relative to terrestrial wired and wireless s: Longer delays and large delay-bandwidth product. High utilization and capacity restrictions of satellite s. atural multicasting capabilities. Large coverage. Multiple spot beams. On-board switching and routing. On-board bandwidth control. Independence from ground infrastructure. This approach of constraining any adaptation of the IETF internet protocols to be fully contained within the boundary of the BSMS is not specific to BSM and can be found in many IP s in the ext Generation etworks (G) such as Virtual Private etworks and Mobile IP. This ensures that the BSMS can be complementary to terrestrial infrastructure, reinforcing the inherent advantages of satellite systems for providing services to remote regions. The different types of BSM IP ing scenarios are summarized in table 4.1. Access scenarios Corporate intranet Corporate internet Table 4.1: BSM IP ing scenarios Point-to-point Multicast Broadcast Corporate VSAT, i.e. site interconnections Internet Access via corporate ISP or via 3 rd party ISP Corporate Multicast e.g. Data distribution e.g. Video conferencing IP multicast RT streaming ISP caching SME intranet Small VSAT SME multicast SME internet Internet Access via 3 rd IP multicast party ISP RT streaming Soho Internet Access via ISP Company access via VP ISP caching IP multicast RT streaming ISP caching Residential Internet Access via ISP IP multicast RT streaming ISP caching Datacasting TV broadcast (private) ISP caching ISP caching ISP caching ISP caching Distribution Point-to-point Multicast Broadcast scenarios Content to Edge ISP to Backbone IP multicast RT streaming Caching at ISP/Edge TV broadcast (public) Core Point-to-point Multicast Broadcast scenarios ISP interconnect Trunk interconnect /A /A

12 TR 101 984 V1.2.1 (2007-12) 5 BSM roles, actors and equipment 5.1 General The following roles and actors are defined as a framework for the business aspects of a BSM. The definitions are designed to provide a clear separation between the different roles, but this strict separation of roles may be less clear in deployed s. The role defines a functional entity that is responsible for a defined set of business processes, where each process implies a set of management functions. The actor defines a real entity, which performs one or more roles. For example, a company is an actor, which can perform more than one role (e.g. etwork Operator and etwork Access Provider, etc.). The roles are linked to the BSM architecture defined in clause 6, and are intended to be compatible with the separation of transport and services as defined for ext Generation etworks (Gs). Selected pieces of equipment are then defined in order to illustrate the responsibilities of the different roles for this equipment. This strict separation of responsibilities may be less clear in deployed s: for example, a single actor (a single business entity) may perform all or most of the roles in a given BSM. 5.2 Roles 5.2.1 Definitions The different roles identified in the whole business interacting with a BSM system are: 1) Operator (SO): The Operator is responsible for maintaining, managing, deploying and operating the satellite platform. The SO business involves launching and operating satellites and selling their transponder capacity to etwork Operators. SO activities are performed at the Control Centre (SCC) and TM/TC (TeleMetry/TeleCommand) stations. 2) etwork Operator (SO): The etwork Operator owns and is responsible for maintaining, managing, deploying and operating the etwork, i.e. leasing satellite transponders and providing the associated ground segment equipment It is responsible for the global traffic and the etwork management functions in terms of availability and performance. It offers a given coverage, connectivity and bandwidth to APs. It manages the partitioning of the resources between the APs according to their contract and is in charge of the satellite payload configuration. It can delegate the actual operations on the satellite to the SO. SO activities are performed at the etwork Operations Centre (OC). 3) etwork Access Provider (AP): The etwork Access Provider uses the services from one or more SOs to provide bulk transmission resources to the Service Providers (SPs) for use by their subscribers. The AP is responsible managing and operating the access elements in the Terminals (s) and one or more Gateways (GWs). The AP typically shares its capacity between several SPs. The AP is linked to each SP by a contract specifying the Service Level Agreement (SLA) of the services that they are allowed to use. The activities of each AP is performed at a given etwork Management Centre (MC) and etwork Control Centre (CC) and at one or several GWs. 4) Service Providers (SP): The Service Provider provides transmission resources to subscribers via one or more of the s associated with that subscriber. The SP is responsible managing and operating the related service provider elements in the Terminals (s) and one or more Gateways (GWs). The SP gives access to a wide range of services involving terrestrial s or not. In the "satellite bandwidth model", they buy bulk (wholesale) capacity from the AP and resell that capacity to their Subscribers. OTE 1: Several types of service provider can be identified. They can be etwork Service Providers (SP) or Application Service Providers (ASP). Examples of SP are Internet Service Providers (ISP) or Corporations (e.g. VP). Examples of ASP are Multicast Service Provider (MSP), Internet Telephony Service Provider (ITSP). Only the Service Providers have a contractual interface with the subscribers: they sell the service and/or the equipment, bill their subscribers, eventually based on information received from the APs.

13 TR 101 984 V1.2.1 (2007-12) 5) Subscriber: The subscriber buys services from SPs. It has a contract with one or several SPs for the provision of services. The subscriber can subscribe for services for one or several s and each can itself serve one or more end hosts (EHs). Usually one of these SPs provides the s to the Subscriber. The subscriber delegates service usage to end-users. 6) User (or end-user): The user is the entity that makes use of the services via an End Host (EH). The EHs can connect directly or via a Local Area or Distribution etwork its ; several EHs and hence several users can share the same. The user (via the EH) is connected to applications provided by SPs. OTE 2: The equipment on the user side (i.e. routers, switches, firewalls etc. that are used to connect the end hosts to the ) is collectively referred to as the Customer Equipment (CPE). 5.2.2 Relationships between roles Figure 5.1 shows the relationships and cardinality between roles: the cardinality of each relationship is indicated by the numbers on each line. Operator (SO) SO VP SP 1 1 Telco SP 1 1 AP 1 Service Providers ITSP ISP MSP 1 Subscriber Subscriber Subscriber The following cardinalities are shown in figure 5.1: Figure 5.1: Relationships between roles a) A single SO can provide services to multiple SOs (cardinality 1:). But equally a single SO can use multiple satellites, including satellites operated by different SOs, to provide services (cardinality :1). This gives an overall cardinality of :. b) A single SO can be associated with multiple APs (cardinality 1:). Likewise a given AP can obtain services from multiple SOs, hence the overall cardinality is :. c) A single AP can be associated with multiple SPs (cardinality 1:). But a given SP can only resell services from a single AP, hence the overall cardinality is 1:. The above definitions only restrict the relationship between roles to 1 AP per SP. However, a single actor can perform multiple roles and hence; a single company (one actor) can be an SP for multiple APs by performing multiple SP roles. Figure 5.1 shows a few different examples of SPs; namely a Corporate Virtual Private etwork SP, a Telco SP or a multiservice SP (ITSP, ISP plus MSP). These are examples only and other types of service provider may exist.

14 TR 101 984 V1.2.1 (2007-12) 5.3 Equipment 5.3.1 Definitions A Gateway (GW) is the equipment that is used to provide interworking between the satellite and one or more external s. Examples of external s include a public giving access to the global internet or a private corporate or even another wireless. A given GW belongs to only one AP: the AP is responsible for the GWs that it uses to provide its services. One or more SPs can be associated with the GW to provide access to their external s. The SPs are responsible for the upper layers of the GW ( layer and above) and they have appropriate visibility and control via the AP. A Terminal () is the equipment that is used to provide interworking between the satellite and one or more users, either via direct connection or via a local. A given may be owned by either the AP or the SP, depending on the business model. In both cases, the management and control of the is made by the AP: the AP is responsible for the lower layers and the SP is responsible for the upper layers and these upper elements are indirectly managed by SP via the AP CC. The overall model of resource management between the SPs and the AP is formalized by a "bandwidth" contract: the SP either pays for a dedicated bandwidth which it partitions between its customers. Alternatively, some SPs may not need to have a dedicated bandwidth but would prefer to pay for bandwidth on a usage basis (session per session). This is formalized by a "wholesale connectivity" contract: the SP pays for a given number of s that are connected, or for a given number of User/ Application sessions which are in progress. These services can be simultaneously delivered by the same AP to one or several SPs through one or several GWs. The Independent Service Access Point (SI-SAP) (as defined in clause 6.4) is recommended as the boundary between the elements for which the SP is responsible and the elements for which the AP is responsible. The SI- SAP is primarily designed to separating the responsibilities of the, but the SI-SAP can also be used to separate the GW responsibilities. 5.3.2 Relationship between roles and equipment Figure 5.2 shows the relationships between equipment and roles: A square shape (square box) corresponds to a piece of equipment. A rounded shape (rounded box) corresponds to one of the roles (as defined above). A solid line between roles represents a business relationship and its cardinality. A solid line between a role and an equipment means the role directly controls some aspects of the equipment. They also define the cardinality of the relationship. A dashed line between a role and an equipment means the role indirectly controls some aspects of the equipment. They also define the cardinality of the relationship. A solid double line between equipment boxes represents a physical interface (communication link) and its cardinality; and a dashed double line between equipment boxes represents a logical interface and its cardinality. This model is valid for both star and mesh system scenarios. One can note the following restrictions of the model: A given SP is related to only one AP. OTE 1: An actual SP actor can be linked to several APs, but in this case a separate SP role would be considered for each AP (an actor can hold several roles). A given is related to one AP, one SP and one Subscriber. The is also linked via the satellite to 0 or 1 Gateway.

15 TR 101 984 V1.2.1 (2007-12) The operations of a given is managed by one MC and controlled by one CC. The MC and CC (MC/CC) are associated with one AP. OTE 2: A may also contain a secondary MC and/or multiple CCs to provide more resilience. The SP may have some indirect control and management of the s via the AP. Likewise, the SP may offer some indirect control and management to the subscriber. OTE 3: A subscriber may subscribe to multiple SPs (and hence use services from multiple APs) but a given can only be associated with a single AP. A given User is related to one End Host and via that End Host to one Customer Equipment (CPE) and one. BSM roles and equipment Other roles and equipment SO 1 AP SP Subscriber User 1 1 1 1 1 1 OC 1 MC/ CC 1 1 1 0 or 1 1 1 Gateway CPE End Host Role-Equipment direct relationship Role-Equipment indirect relationship Role-Role relationship Physical interface between Equipment Logical interface between Equipment Figure 5.2: Relationship between roles and equipment 5.4 Billing and usage relationships An example of the billing and usage relationships that could exist between the satellite operators and service providers and some other roles is illustrated in figure 5.3.

16 TR 101 984 V1.2.1 (2007-12) Subscribers usage delegation subscription usage payment billing usage payment etwork Operators and Service Providers (access providers, connectivity providers) billing agreement Content Providers Users Receive service / content Figure 5.3: Billing and usage relationships OTE: Figure 5.3 shows the billing and usage relationships that affect the satellite operators and service providers. Additional billing and usage relationships that may exist (e.g. between Users and content providers) are out of scope for the present document and hence are not shown in this figure. 6 BSM reference models and architectures 6.1 Definitions 6.1.1 BSM System; etwork and Sub The following three groupings of BSM elements are defined (in order of decreasing complexity): BSM System (BSMS): A BSM System corresponds to a BSM etwork together with the MC and CC plus any additional elements that are required to provide the services to the subscribers and their users. OTE 1: The MC and CC represent a functional separation of the management and control functions and does not imply any particular implementation. BSM etwork: A BSM corresponds to a BSM sub together with the BSM interworking and adaptation functions that are required to provide an interface into the attached s. OTE 2: The boundaries of the BSM etwork are the physical interfaces to those attached s. BSM Sub: A BSM sub is all the BSM elements below the Independent Service Access Point (SI-SAP). OTE 3: The Independent Service Access Point (SI-SAP) is the interface between the satellite dependent lower layers and the satellite independent upper layers of the Terminal air interface. The SI-SAP is described in clause 6.4.

17 TR 101 984 V1.2.1 (2007-12) MC CC SATELLITE TERMIAL () (User ) GATEWAY (GW) (Gateway ) User Interworking Function (UIF) Peer-to-peer IP traffic Independent Interface (SI-SAP) Gateway Interworking Function (GIF) To / from etwork etwork Interface etwork Interface payload etwork Interface External etwork Interface To / from External etwork BSM Sub BSM etwork BSM System Figure 6.1: BSM System, etwork and Sub Figure 6.1 also illustrates two main types of satellite terminals (s): Terminal (User ): A User provides interworking between the satellite and a premises. OTE 4: A premises provides a connection to one or more end hosts, either via direct connection or via a local such as a LA. Gateway (Gateway ): A Gateway provides interworking between the satellite and an external. OTE 5: An external provides access to the global internet and/or to a company servers, and/or similar shared access. This model illustrates a functional difference in the interworking function provided by a User and a Gateway. The same type of equipment may be used in both cases and in some cases a given may provide both types of interworking function within the same physical. The functionality provided by a given is also dependent on the satellite architecture and the topology, as described in the following clauses. 6.1.2 Transparent and regenerative satellite architecture A BSM may use either a transparent or a regenerative satellite architecture: A transparent satellite architecture refers to a single architecture, commonly called a "bent-pipe architecture". In this architecture the satellite payload only contains physical layer functions (e.g. transponders) and does not terminate any other layers of the air interface in the satellite. The satellite payload transfers each set of uplink signals to the corresponding downlink transparently. A regenerative satellite architecture is the range of other architectures that provide additional functionality in the satellite payload. In these architectures, the satellite payload contains functions at the physical layer and at other layers. The satellite payload typically terminates the physical layer plus one or more other layers of the air interface.

18 TR 101 984 V1.2.1 (2007-12) 6.1.3 Topologies The topology refers to the arrangement of the links (logical links) between the Hub and the s and between s via the satellite. A BSM may support either a mesh or star topology as illustrated in figure 6.2: A star topology is defined by the star arrangement of links between the Hub (or Gateway ) and multiple remote s. In this topology the User is usually referred to as the "Remote " (or simply "") and the Gateway is usually referred to as the "Hub". A Remote can only establish a direct link with the Hub and cannot establish a direct link to another Remote. A mesh topology is defined by the mesh arrangement of links between the s, where any can link directly to any other. In this topology any can perform the functions of a User or a Gateway. The star topology can be considered as one special case of the mesh topology. OTE: A star topology can be used to provide mesh connectivity by establishing an indirect "double-hop" link between remote s via the Hub station. satellite Hub satellite Star topology Mesh topology Figure 6.2: Star and Mesh topology 6.1.4 Link and channel attributes Within either a star or mesh topology, the links can have the following attributes: Point-To-Point links. Point-To-Multipoint links. Multipoint-To-Multipoint links. Multipoint-To-Point links. Broadcast links. Links (both logical and physical) between an and the satellite can be defined by reference to the direction of the link relative to the as follows: UpLink (UL): a link from the to the satellite (i.e. a link transmitted by the ). DownLink (DL): a link from the satellite to the (i.e. a link received by the ).

19 TR 101 984 V1.2.1 (2007-12) These definitions are illustrated in figure 6.3. forward channel outbound channel inbound channel Hub return channel Remote #1 inbound channel outbound channel #2 Star topology: forward and return channels Mesh or Star topology: outbound and inbound channels Figure 6.3: Links and channels Channels (both logical and physical) can also be defined by reference to the topology as illustrated in figure 6.3. In the case of a Star topology we can define the direction of a channel as follows: Forward channel: a channel from the central hub to the remote s. Return channel: a channel from one of the remote s to the central hub. In the case of a Mesh or Star topology we can define the direction of a channel at a given as follows: OutBound channel (OB): a channel originating from the (i.e. the is the data source). InBound channel (IB): a channel terminating at the (i.e. the is the data sink). OTE: OutBound and InBound channel definitions are relative to a given. An OutBound channel from one becomes the Inbound channel at the peer. 6.2 BSM etwork Types 6.2.1 aming conventions BSM s can be classified into one of three different types according to the satellite OBP architecture, the return channel and the topology. The main BSM types are summarized in table 6.1 using the naming conventions defined in TR 102 187 [9]. Table 6.1: BSM etwork Types BSM etwork Type TSS TSM RSM OBP Architecture Transparent Transparent Regenerative Return Channel etwork Topology Star Mesh Mesh All of these three main types use a return channel. However, the BSM architecture can also be applied to s that use a Hybrid (non-satellite) return channel with the addition of an additional interface as shown in annex C.

20 TR 101 984 V1.2.1 (2007-12) There are two main differences between these different types of BSM : d) The cardinality of the relationship between the User s and the Gateway s is restricted to :1 for a star topology (i.e. a given User is associated with only one Gateway ) but can be : (any to any) for a mesh topology. OTE: As noted in clause 6.1.3 the star topology can be considered as a special case of the mesh topology and hence a that supports mesh connectivity can also support star connectivity. e) The Radio Interface is usually different in the forward and reverse directions. For a transparent satellite this means that the Gateway and the User usually have a different satellite radio interface (i.e. the Uplink and Downlink are reversed at the Gateway relative to the User s); but in the case of a regenerative satellite the s on both sides usually have the same satellite interface (i.e. the Uplink and Downlink are the same at both the User s and the Gateway s). An example of each of these main types, illustrating and elaborating these differences, is given in the following clauses. Clause 6.3 then defines a set of generic reference models that are applicable to all of the different types. 6.2.2 Transparent Star (TSS) In a transparent satellite star the communication links between the Terminals (s) and the Gateway/ etwork Control Centre (GW/CC) use a transparent satellite architecture. The satellite links are bidirectional and both directions (both forward and return links) use a transparent satellite architecture. A schematic diagram for a transparent satellite star BSM sub is shown in figure 6.4. subnet A subnet A Transparent Star links for User Data and Control Data GW/ CC ISP ISP Router Router Global Global Backbone Internet Backbone Internet Content server Router subnet B subnet B BSM sub Other Other terrestrial terrestrial Server The following points are noted in this example: Figure 6.4: Transparent Star (TSS) a) The BSM sub uses a star topology for all links. In this example a single Hub connects to multiple remote s. b) The GW/CC represents the Gateway at the Hub of the star topology that is shared by the Gateway functions and the CC. The GW element contains the IP interworking functions and the CC element processes the control data (C-plane). OTE 1: It is also possible to use separate s for the GW and CC elements.

21 TR 101 984 V1.2.1 (2007-12) c) The represents the remote (the User ) of the star topology. Typically, each customer premises will have a separate connected to their local premises subnet, but it is also possible to connect multiple independent subnets via a single remote. d) The radio interface is usually different in the forward and reverse directions. OTE 2: For example, a typical TSS may use DVB-S or DVB-S2 for the forward link and DVB-RCS for the reverse link. e) The forward links can support either point-to-point links (to a single remote ) or point-to-multipoint links (to multiple remote s.). The reverse link can only support point-to-point links from any remote to the GW/CC. OTE 3: A remote can act as the indirect source for point-to-multipoint services by forwarding the data via the GW (i.e. double hop). f) The forward and reverse links use multiplexing to combine the traffic for multiple different User s into the available channels. OTE 4: The reverse links typically use Demand Assigned Multiple Access (DAMA) protocols to assign some or all of the capacity to s on a demand driven (per-request) basis. However, other capacity assignment methods (e.g. reserved fixed rate capacity) are also possible. 6.2.3 Transparent Mesh (TSM) In a transparent satellite mesh direct single-hop communication between two remote s (User s) is permitted using a transparent satellite architecture. The transparent mesh can only exist as an overlay to a transparent satellite star : the mesh overlay is only used for user data and the star is used for both control data to/from the CC and for user data to/from the GW. The satellite links are bidirectional (for both the mesh and the star links) and all these links use a transparent satellite architecture. A schematic diagram for a transparent satellite mesh BSM sub is shown in figure 6.5. subnet A subnet A Transparent Mesh links for User Data Overlaid on Transparent Star links for User Data and Control Data GW/ CC ISP ISP Router Router Global Global Backbone Internet Backbone Internet Router Content server subnet B subnet B BSM sub Other Other terrestrial terrestrial Server The following points are noted in this example: Figure 6.5: Transparent Mesh (TSM) a) The BSM sub contains both a mesh and a star topology. The star topology is identical to the transparent star described in clause 6.2.2. The mesh topology can be used to provide direct, single-hop links between pairs of remote s.

22 TR 101 984 V1.2.1 (2007-12) b) The remote is required to provide additional processing to handle the mesh links, since the mesh link transmissions from another remote will typically use a different radio interface to the star link transmissions from the GW/CC. OTE: For example, in a DVB system the star link from the GW/CC may use DVB-S2 but the mesh link from the other remote may use DVB-RCS. In this example the remote s transmit using DVB-RCS for both mesh links and star return links. c) The mesh links are controlled by the CC using additional mesh control procedures via dual transparent star control links from each remote to the CC (a separate control link is needed for each remote ). d) The mesh topology can support both point-to-point or point-to-multipoint links. 6.2.4 Regenerative Mesh (RSM) In a regenerative satellite mesh direct single-hop communication between any two Terminals (User s or Gateway s) is possible using a regenerative satellite architecture. A star topology is also possible as a special case of this fully meshed topology, with any acting as the Gateway (i.e. as the "hub") for a set of star links. As a result, a regenerative satellite star (RSS) type is not considered as a separate type: it is included in the RSM type. The mesh links are used to provide single-hop links for user data between any two terminals. Typically this is combined with a separate set of star links for the control data between both s and the CC. In general, this means that the GW function is both physically and logically separated from the CC. A schematic diagram for a regenerative satellite mesh BSM sub is shown in figure 6.6. subnet A subnet A Regenerative Mesh or Regenerative Star links for User Data combined with Regenerative Star links for Control Data GW ISP ISP Router Router Global Global Backbone Internet Backbone Internet Content server Router subnet B subnet B BSM sub CC Other Other terrestrial terrestrial Server The following points are noted in this example: Figure 6.6: Regenerative Mesh (RSM) a) The BSM sub contains a variable mix of mesh and star topologies. Any can act as a Gateway for user data. b) The radio interface is typically different for the uplink ( to satellite) and the downlink (satellite to ). But all of the s can use the same radio interface since the regenerative satellite payload converts from the uplink radio interface to the downlink radio interface as part of the payload processing. c) The complete (both star and mesh links) is controlled by the CC via star topology control links between each and the CC (a separate control link is needed for each active ). OTE 1: Typically a dedicated is used by the CC to transmit and receive the control links. d) This meshed topology can support both point-to-point or point-to-multipoint links.

23 TR 101 984 V1.2.1 (2007-12) e) The forward and reverse links for the mesh topology also use multiplexing to combine the traffic for multiple different s into the available radio channels. The uplink typically uses Demand Assigned Multiple Access (DAMA) protocols to assign capacity to s on a demand driven (per-request) basis. OTE 2: The uplink traffic from a given may be connected to multiple different downlink channels via the regenerative satellite payload and hence the uplink capacity allocations may need to take account of downlink capacity restrictions as well as any uplink capacity restrictions. 6.3 Reference models 6.3.1 Reference models for access scenario This clause gives a detailed reference model for the satellite access scenario. The reference interfaces are divided into physical and logical interfaces defined as follows: Physical interfaces correspond to physical connections between equipment, either wired or wireless, typically corresponding to physical transmissions over a wired or wireless medium. Logical interfaces correspond to logical associations between peer protocol entities, typically corresponding to peer-to-peer protocol message exchanges using one or more logical channels that are transported via one or more physical channels. 6.3.1.1 U-plane reference model The U-plane reference model is shown in figure 6.7. Each labelled interface is described in more detail in the corresponding table 6.2. KEY End End Host Host Physical interface U-plane Logical interface etwork Interface Interworking & Adaptation SI-SAP SD SD Lower Lower Layers Layers Interworking & Adaptation SI-SAP SD SD Lower Lower Layers Layers Gateway etwork Interface End End Host Host User payload payload Gateway External External T U/U U/U GW G Figure 6.7: U-plane reference model for satellite access

24 TR 101 984 V1.2.1 (2007-12) Table 6.2: U-plane interfaces for satellite access Ref Physical interface ame Description of interface T / External etwork Interface Interface between User and premises G / External etwork Interface Interface between Gateway and external U / U / etwork Interface Radio Interface for User (see note 1). U / U GW / etwork Interface Radio Interface for Gateway (see note 1). OTE 1: The radio interface label U indicates that both sides have the same radio interface. Alternatively the radio interface labels U and UGW indicate that the two sides have a different radio interface (i.e. the User and the Gateway have a different radio interface). OTE 2: The SI-SAP interface is described in clause 6.4. Three logical interfaces are shown at the radio interface, corresponding to the peer-to-peer interactions of the different layers of radio interface protocols. The SD lower layers of each have two logical interfaces: one interfacing with the satellite payload and one with the peer. The boundary between these two interfaces is satellite dependent (i.e. it depends on the satellite payload capabilities). As shown in this reference model, IP InterWorking Functions (IP IWFs) occur at two points: In the User, IP IWFs provide interworking and adaptation between the BSM SI-SAP and the etwork. In the Gateway, IP IWFs provide interworking and adaptation between the BSM SI-SAP and the External etwork. In both cases, these IP IWFs are logical entities and no particular physical location is implied by their position in the reference diagram. 6.3.1.2 C-plane and M-plane reference model The C-plane and M-plane reference model is shown in figure 6.8. Each labelled interface is described in more detail in the corresponding table 6.3. KEY C-plane/ M-plane Logical interface M etwork Control etwork Control Centre (CC) Centre (CC) etwork etwork Management Management Centre (MC) Centre (MC) M U-plane U-plane Interworking & Adaptation C-plane C-plane M-plane M-plane SI-SAP SI-SAP SI-SAP SD Lower SD Lower Layers Layers payload payload M-plane M-plane C-plane C-plane SI-SAP SI-SAP SD Lower SD Lower Layers Layers U-plane U-plane Interworking & Adaptation SI-SAP User Gateway Figure 6.8: C-plane and M-plane reference model for satellite access

25 TR 101 984 V1.2.1 (2007-12) Table 6.3: C-plane and M-plane Interfaces for satellite access Ref Logical interface ame Description of interface Control interface between CC and Internal C-plane protocols M Management interface between MC and Internal M-plane protocols OTE: The SI-SAP interface is described in clause 6.4. As shown in this diagram, both the MC and CC have a logical interface to the User s and to the Gateway s. 6.3.2 Generalized reference models The detailed reference model as defined above for the access scenario can now be applied to the different types and to the other BSM scenarios. 6.3.2.1 BSM types The access reference model can be applied to all the BSM types. Two variants of the U-plane reference model are noted as illustrated in figure 6.9. BSM or T User U satellite payload U GW Gateway G Access scenario using star topology or BSM or T/G Any U satellite payload U Any T/G Access scenario using mesh topology Backbone router Edge router Local router Figure 6.9: U-plane reference models for different types For the star topology, only one reference model is possible, with the BSM proving an access link between the external attached to a Gateway and the premises attached to a User. For the mesh topology, several similar reference models are possible. The BSM can provide an access link between any two terminals: either two User s, two Gateway s or one of each. 6.3.2.2 Other BSM scenarios The access reference model can also be applied to the other scenarios defined in clause 4 as shown in figure 6.10. These mappings differ only in the functionality provided by the satellite terminals: for the core and distribution scenarios, both ends of the BSM are provided by Gateway functions.

26 TR 101 984 V1.2.1 (2007-12) BSM or G Gateway #1 U GW satellite payload U GW Gateway #2 G Content Distribution scenario BSM G Gateway #1 U GW satellite payload U GW Gateway #2 G Core scenario Backbone router Edge router Local router Figure 6.10: U-plane reference models for other BSM scenarios As shown in figure 6.10, a BSM can provide data transport services between any pair of G interfaces. 6.4 Protocol architecture 6.4.1 BSM protocol architecture The BSM protocol architecture for satellite access terminal to satellites is illustrated in figure 6.11. Independent upper layers IPV4 or IPV6 Independent Adaptation Functions Dependent lower layers r e y a L k i n L a t a D l a ic s y h P r e y a L SI-SAP Dependent Adaptation Functions Link Control (SLC) Medium Access Control (SMAC) Physical (SPHY) Figure 6.11: BSM protocol architecture The different layers of the BSM protocol architecture are defined in table 6.4. Table 6.4: Main layers of the BSM protocol architecture Layer Description of Layer Comments 1 PHYSICAL LAYER (PHY) Physical Layer (SPHY) dependent layer conforms to Harmonized Standards 2 DATA LIK LAYER (DLL) Link Control (SLC) and Medium Access Control (SMAC) dependent layer SLC and SMAC may be combined into a single layer, or may be separate sublayers 3+ IP LAYERS (and higher layers) independent layers

27 TR 101 984 V1.2.1 (2007-12) As shown in figure 6.11, the Independent Service Access Point (SI-SAP) is the interface between the satellite dependent lower layers and the satellite independent upper layers. The SI-SAP and the associated adaptation functions are described in clause 6.4.3. 6.4.2 SI-SAP and BSM families The BSM protocol architecture supports families of air interface protocols, where each family defines a complete stack of air interface protocols for the physical layer and the data link layer. Each air interface family is expected to use a combination of a SLC, SMAC and SPHY layers that are jointly optimized for a specific range of satellite architectures and/or for a specific range of traffic types. The naming conventions for BSM families are defined in TR 102 187 [9]. Independent upper layers (common) IPV4 or IPV6 IPV4 or IPV6 IPV4 or IPV6 Independent Independent Independent Adaptation Layer Adaptation Layer Adaptation Layer SI - SAP SI - SAP SI- SAP Dependent Dependent Dependent Adaptation Layer -A Adaptation Layer -B Adaptation Layer -C Families of Dependent lower layers DLL-A (SLC & SMAC) PHY-A OR DLL-B (SLC & SMAC) PHY -B OR DLL-C (SLC & SMAC) PHY-C FAMILY A FAMILY B FAMILY C Figure 6.12: BSM families The concept behind the BSM protocol architecture is a clear separation between functions that are applicable to all satellite systems (satellite independent or SI) and the functions that are specific to a satellite technology (satellite dependent or SD) and hence define a satellite independent interface that can be used to provide essentially the same services across all families (i.e. across all implementations of the BSM SD layers). This interface is called the Independent Service Access Point (SI-SAP); a common interface that applies to all air interface families. 6.4.3 Independent Service Access Point (SI-SAP) The Independent Service Access Point (SI-SAP) is the common interface between any BSM family of satellite dependent lower layers and the satellite independent upper layers. The BSM protocol architecture also defines two sets of adaptation functions that are associated with the SI-SAP. These functions are used to provide a mechanism for adapting to and from the SI-SAP services: The Independent Adaptation Functions (SIAF) operate at the bottom of Layer 3 to adapt between the layer 3 protocols and the SI-SAP services. The Dependent Adaptation Functions (SDAF) operate at the top of Layer 2 to adapt between the SI-SAP services and the native services of the given BSM family. As shown in figure 6.4.3 the SI-SAP and the associated adaptation functions can be logically divided into U-plane, C-plane and M-plane services. This is a logical (functional) separation of the SI-SAP interface functions and does not imply any particular physical implementation of the interface. The SI-SAP U-plane services correspond to the endpoints of the BSM bearer services as described in clause 6.4.4. The SI-SAP is used to define a common set of satellite independent bearer services that are mapped (via the SDAF) into the satellite dependent lower layer services. This enables and other standards bodies to define standard mappings from the higher layers to these BSM bearer services via the SIAF.

28 TR 101 984 V1.2.1 (2007-12) Independent U-plane SIAF C-plane SIAF M-plane SIAF SI-U-SAP SI-C-SAP SI-M-SAP U-plane SDAF C-plane SDAF M-plane SDAF Dependent Link Control (SLC) Medium Access Control (SMAC) Physical (SPHY) Figure 6.13: Independent Service Access Point (SI-SAP) 6.4.4 BSM bearer services layered architecture BSM bearer services are defined in terms of a layered architecture that is based on the 3GPP QoS architecture [4]. BSM bearer services are the user plane (U-plane) data transmission services provided by the BSM sub at the SI-SAP interfaces. BSM bearer services include all aspects to enable the provision of U-plane data transport service between SI-SAP interfaces, including both the contracted QoS and other bearer service properties, as viewed at those SI-SAP interfaces. OTE: BSM bearer services do not include the associated control plane (C-plane) and management plane (M-plane) services such as control signalling and QoS management functionality. The layered architecture for bearer services is illustrated in figure 6.14, showing how each bearer service on a specific layer offers it is individual services using services provided by the layers below. The BSM bearer services use service provided by the underlying native bearer services, which in turn use the services of the transmission bearer services. The BSM bearer services are defined with more detail in clause 8.

29 TR 101 984 V1.2.1 (2007-12) End System A Terminal A Terminal B End System B TCP transport services & IP services External Bearer Service SI-SAP BSM Bearer Service SI-SAP External Bearer Service ative bearer service Transmission bearer service Transmission bearer service Figure 6.14: BSM bearer services A BSM system will typically use a combination of different native bearer services and transmission bearer services (i.e. different channels) to support a range of BSM bearer services. The higher layer services (IP and above) are built on the BSM bearer services and these higher layer services can be mapped to different BSM bearer services depending on the particular service requirements (e.g. the quality of service and the topology required). 6.4.5 Air interface lower layer service elements Figure 6.15 illustrates the relationship between the BSM bearer services and the underlying lower layer bearer services and associated elements of service at the different layers of the satellite air interface.

30 TR 101 984 V1.2.1 (2007-12) Independent Adaptation Functions SI- SAP BSM BEARER SERVICES Independent Adaptation Functions SI -SAP Dependent Adaptation Functions Logical Channels Link Control (SLC) Medium Access Control (SMAC) ATIVE BEARER SERVICES Data Links Dependent Adaptation Functions Logical Channels Link Control (SLC) Medium Access Control (SMAC) Physical Channels Physical (SPHY) TRASMISSIO BEARER SERVICES Physical Links (radio links) Physical Channels Physical (SPHY) Figure 6.15: Air interface lower layer elements of service Figure 6.15 shows both the layered bearer services and the associated peer-to-peer relationships at each layer. Typically the layer to layer interfaces are defined in terms of primitive exchanges and the peer-to-peer interfaces are defined in terms of message or Protocol Data Unit (PDU) exchanges. The following bearer services are defined: BSM bearer services are the user data transfer services provided at the SI-SAP interfaces as illustrated above. ative bearer services are the lower layer data transfer services provided at the SLC/SMAC interfaces of the s as illustrated above. OTE 1: The Dependent Adaptation Functions (SDAF) are used to adapt between the ative bearer services (which are family dependent) and the BSM bearer services. Transmission bearer services are the data transmission services provided by the Physical Layer interfaces of the s as illustrated above. The following layer-to-layer elements of services are defined: The SI-SAP is the Independent Service Access Point as defined in clause 6.4.3. Logical channels are the channels that correspond to the native bearer services (i.e. a logical channel corresponds to the endpoint of a specific instance of the native bearer services). Physical channels are the transmission bearer services provided by the physical layer protocols (i.e. a physical channel corresponds to the endpoint of a specific instance of the transmission bearer services). The following peer-to-peer elements of service are also defined: A data link is defined as the capability of the data link layer to exchange data. This is a peer-to-peer association at the data link layer. The peer entity for the data link of a given may be either the satellite payload or another depending on the capabilities of the satellite payload. OTE 2: A data link will typically support multiple logical channels (e.g. by multiplexing). A physical link is defined as the capability of the physical layer to exchange data. This is a peer-to-peer association at the physical layer. OTE 3: A physical link will typically support multiple physical channels (e.g. by multiplexing).

31 TR 101 984 V1.2.1 (2007-12) 7 General service definitions 7.1 Media components The telecommunication services supported by involve in general one or more media components. The following types of media components are distinguished in the present document: speech: voice telecommunication. audio: telecommunication of sound in general. video: telecommunication of full motion pictures, and of stills. data: telecommunication of information-files (text, graphics, etc.). MultiMedia (MM): a combination of two or more of the above components (speech, audio, video, data), with a temporal relationship (e.g. synchronization) between at least two components. 7.2 BSM connections A BSM connection provides a means for communication between two or more devices in, or attached to, a Broadband Multimedia telecommunication. In the case of IP traffic, BSM connections are referred to as "flows": IP Flows (Flows) are defined as a sequence of IP packets that are routed (end-to-end), based on the destination IP address contained in the IP header. An IP flow is a logical concept introduced to describe IP traffic at a particular node. IP packets belonging to the same flow can (and often do) travel via differing sets of nodes. An IP Flow may be associated with a traffic class and a path through a using the Integrated services (Intserv) model, in which case reservations are made using RSVP. IP s may also support traffic classes without explicit reservation using the Differentiated services (Diffserv) model. Intserv and Diffserv are described in more detail in TR 101 865 [5], clause 8.2. IP Flows are identified in nodes on the basis of information found in the IP datagram header fields (e.g. IP source and destination address, source and destination port, protocol ID, Type Of Service (TOS) field). In case of ATM traffic, BSM connections are referred to as "virtual circuits": Virtual circuits are defined as a sequence of ATM cells that are switched identically based on a label that is unique on a link per link basis, and contained in the ATM header (i.e. the Virtual Channel Identifier (VCI) + Virtual Path Identifier (VPI)). From a perspective, a virtual connection is an edge-to-edge service, travelling from one edge of a to another edge. Virtual circuits are established by means of signalling on the basis of ATM End System Addresses (AESA) e.g. as defined by ATMF in af-uni-0010.002 [3]. Virtual connections are identified in ATM switches on the basis of the VCI/VPI. ATM edge devices are seldom co-located with the end hosts, and are more often co-located with IP routers. 7.3 BSM service capabilities Existing systems have largely standardized the complete sets of teleservices, applications and supplementary services which they provide. As a consequence, substantial re-engineering is often required to enable new services to be provided and the market for services is largely determined by operators and standardization. This makes it more difficult for operators to differentiate their services.

32 TR 101 984 V1.2.1 (2007-12) BSM will therefore standardize service capabilities and not the services themselves. Service capabilities consist of bearer services defined by QoS parameters and the mechanisms needed to realize and access those bearer services. These mechanisms include the functionality provided by various elements, the communication between them and the storage of associated data. Clause 6 provides a conceptual description of a service architecture and architecture requirements which aim to provide service capabilities. It is intended that these standardized capabilities should provide a defined platform which will enable the support of speech, video, multi-media, messaging, data, other teleservices, user applications and supplementary services and enable the market for services to be determined by users and home environments. OTE: This is based on the approach used in the 3GPP specifications [2]. 7.4 Interoperability Interoperability can be defined at several different levels as follows: Terminal interoperability is defined as the ability of a Terminal () designed and built according to given standards to interoperate with a satellite system designed and built independently to the same standards and to provide a defined profile of services. OTE 1: Terminal interoperability implies that a conforming terminal could be used to access more than one BSM satellite system using the same BSM family. In addition, any manufacturer can use the standards to design and produce interoperable terminals for that family. Protocol interoperability is the ability to operate the same protocols over different systems. OTE 2: Protocol interoperability implies that a BSMS should support a specified set of protocols, for example IPv4 and related IP layer protocols, including BSM defined adaptations of IETF protocols. Service interoperability is the ability to offer the same services over different systems. Once protocol interoperability between s is attained, service interoperability is dominated by the respective Service Level Agreements (SLAs) of the interoperating s. OTE 3: Service interoperability implies that BSM s should support an open service interface, in principle allowing the possibility of 3 rd party service providers offering services over their s. 8 Bearer services 8.1 Definitions 8.1.1 Telecommunications bearer services Telecommunications bearer services provide the capability for information transfer between access points, typically the User-etwork Interface. These functions are sometimes referred as low layer capabilities (in reference to OSI layers). The user may choose any set of high layer protocols for his communication and these telecommunications bearer services do not ascertain compatibility at these layers between users. The characterization of a telecommunication bearer service is made by using a set of characteristics that distinguishes it from other bearer services. Particular values are assigned to each characteristic when a given bearer service is described and defined. In the general case, the s between the two access points can use different control mechanisms. In this case the bearer services of each throughout the communication link have to be translated at the interfaces to realize an end to end bearer service. Each contributes to the end-to-end QoS perceived by the end-user. Therefore all of the intervening s (between two access points) have to attain service interoperability in order to support the end-to-end QoS.

33 TR 101 984 V1.2.1 (2007-12) 8.1.2 Connectionless and connection-oriented bearer services Connectionless bearer services refer to services which allows the transfer of information between users without the need for separate connection establishment procedures. Connection-oriented bearer services refer to services in which communication proceeds through three well-defined phases: connection establishment, data transfer, connection release. 8.1.3 Unidirectional and bidirectional bearer services Bearer services may be unidirectional or bidirectional as follows: unidirectional bearer service: bearer service where data are transferred in one direction only from the source user- interface to the destination user- interface(s). bidirectional bearer service: bearer service where data are transferred in both directions between the source user- interface(s) and the destination user- interface(s). OTE: A bidirectional bearer service can be realized by combining two or more unidirectional bearer services in opposite directions. 8.1.4 Bearer service symmetry Bidirectional bearer services may be symmetric or asymmetric. For asymmetric bearer services the service may define a forward direction and a reverse direction as follows: forward direction: dominant direction of data transfer over an asymmetric. It corresponds to the direction with better link characteristics in terms of bandwidth, latency, error rate, etc. We term data transfer in the forward direction as a "forward transfer". reverse direction: direction in which acknowledgements of a forward TCP transfer flow. Data transfer could also happen in this direction (and it is termed "reverse transfer"), but it is typically less voluminous than that in the forward direction. OTE: These definitions are adopted from the IETF PILC Working Group (PILC WG). 8.1.5 Bearer service configurations The following bearer service configurations are defined: Point-To-Point Bearer Service: a unidirectional service in which one or more packets are sent from a single source "A" to a single destination "B". Point-To-Multipoint Bearer Service: a unidirectional service in which one or more packets are sent from a single source "A" to one or more destinations "D1", "D2", "Dn". Multipoint-To-Multipoint Bearer Service: a unidirectional service in which one or more packets are sent from any one of a defined group of sources "C1", "C2", "Cn" to one or more destinations "D1", "D2", "Dn". The source group "C1", "C2", "Cn" may overlap in whole or in part with the destination group "D1", "D2", "Dn". Broadcast Bearer Service: a unidirectional service in which one or more packets are sent from any one of a defined group of sources " "C1", "C2", "Cn" to an unaddressed group of destinations. OTE: The broadcast bearer service differs from the multipoint services by using a broadcast address for transmission.

34 TR 101 984 V1.2.1 (2007-12) 8.2 BSM bearer services 8.2.1 General BSM bearer services are the user plane (U-plane) data transfer services provided at the SI-SAP interfaces. A BSM bearer service defines all the properties of the user-data transfer between SI-SAP interfaces, including both the contracted QoS and other bearer service properties. OTE: The SI-SAP interface is defined in clause 6.4.3. A range of BSM bearer services is possible, combining the QoS properties of the service with a selection of other characteristics as described above. In general, the characteristics of the available bearer services will be satellite dependent. 8.2.2 Queue Identifiers (QIDs) The SI-SAP U-plane interface defines an abstract representation of the available bearer services via a series of SI-SAP labels called Queue Identifiers (QIDs). A QID is a local label that identifies a specific bearer service at the SI-SAP of the sending : the QID is only used at the SI-SAP interface and is not transmitted to the receiving. QIDs are used as labels to identify the wanted bearer service when sending user data and are also used as the labels for controlling those bearer services as follows: In the U-plane a specific QID is associated when sending data - i.e. associated with every sending-side user data transfer via the SI-SAP. The satellite dependent layers are responsible for mapping these SI-SAP bearer services to the appropriate native bearer services and assigning satellite capacity in order to transport the user data in accordance with the QoS and other properties associated with that QID. In the C-plane the lower layers resources can be dynamically controlled (e.g. to open, close or modify bearer services) using SI-SAP primitives. Each bearer service is identified by a QID and hence the QID is used in the C-plane primitives as the label to identify the relevant bearer service. This C-plane control of bearer services is optional: QIDs may also be assigned statically (e.g. invoked only by management configuration) and hence C-plane control is only required in cases of dynamic control of QIDs via the SI-SAP. The QoS properties associated with a given QID are defined by QoS specific parameters and each QID is mapped onto suitable lower layer transfer capabilities (e.g. to different capacity request categories in the DVB-RCS model) in order to realize that QoS. Some QID could be assigned statically and others could be dynamically created to satisfy certain QoS. The QID however is not limited to the QoS properties (e.g. to a capacity allocation class); it also relates to other flow/behaviour properties of the BSM bearer service. For example a QID may be associated with a specific set of satellite connectivity resources such as a specific transponder, or a specific set of satellite spot beams, or even a specific range of destination addresses, in order to reflect differences in the bearer services that are linked to these additional satellite specific properties. However, in all cases, any such satellite dependent properties are abstracted (or hidden) behind the single QID which provides a single label for the complete aggregate properties of the BSM bearer service. Queue Identifiers (QIDs) are defined in more detail in the SI-SAP Guidelines [6] and the SI-SAP specification [7]. The BSM traffic classes are central to the concept of the QID. Traffic classes available at the SI-SAP describe QoS, performance management and resource allocation and they are defined in detail in TS 102 295 [8].

35 TR 101 984 V1.2.1 (2007-12) Annex A: Example protocol models A.1 A protocol model for regenerative satellites A protocol model for a satellite with On Board Processing (OBP) is illustrated in figure A.1. The SIAF provides a local mapping from the standard TCP/IP traffic into the SI-SAP in order to provide peer-to-peer transport of TCP/IP traffic between s. USER SATELLITE GATEWAY TCP/IP interworking Peer-to-peer IP traffic TCP/IP interworking To/from etwork etwork Interface SIAF SI-SAP SDAF SATELLITE LIK COTROL MEDIUM ACCESS COTROL radio interface Independent Interface (SI-SAP) MEDIUM ACCESS COTROL radio interface SIAF SDAF SI-SAP SATELLITE LIK COTROL MEDIUM ACCESS COTROL External etwork Interface To/from External etwork PHYSICAL PHYSICAL PHYSICAL PHYSICAL T U BSM Sub U GW G Figure A.1: Protocol model for satellite with OBP A.2 A protocol model for transparent satellites A protocol model for a transparent satellite is illustrated in figure A.2. The SIAF provides a local mapping from the standard TCP/IP traffic into the SI-SAP in order to provide peer-to-peer transport of TCP/IP traffic between s. In this case, no MAC layer processing is performed by the satellite. SATELLITE TERMIAL () (USER ) SATELLITE GATEWAY (GW) (GATEWAY ) TCP/IP interworking Peer-to-peer IP traffic TCP/IP interworking To/from etwork etwork Interface SIAF SI-SAP SDAF SATELLITE LIK COTROL MEDIUM ACCESS COTROL radio interface Independent Interface (SI-SAP) radio interface SIAF SDAF SI-SAP SATELLITE LIK COTROL MEDIUM ACCESS COTROL External etwork Interface To/from External etwork PHYSICAL PHYSICAL PHYSICAL PHYSICAL T U BSM Sub U GW G Figure A.2: Protocol model for transparent satellite

36 TR 101 984 V1.2.1 (2007-12) Annex B: Topology examples Examples of mesh topology and star topology are illustrated in figures B.1 and B.2 respectively. BSM IP etwork Control Centre IP End Hosts (source) T User U payload U GW Gateway G End Hosts (destination) T G IP router BSM node U-plane interfaces Physical interface Logical interface C-plane interfaces Logical interface Figure B.1: Example of Mesh topology As illustrated in figure B.1, the etwork Control Centre (CC) for a mesh topology is typically a separate element from the satellite terminals. The satellite terminals can provide either a user side interface (T interface) or a gateway side interface (G interface). BSM IP etwork Control Centre IP End Hosts (source) T Remote U payload U GW Hub/GW G End Hosts (destination) T G IP router / IP bridge BSM node U-plane interfaces Physical interface Logical interface C-plane interfaces Logical interface Figure B.2: Example of Star topology As illustrated in figure B.2, the etwork Control Centre (CC) for a star topology is typically co-located with the Hub/ Gateway. Other GW locations are also possible: the may have multiple GWs and some or all of these may be located separately from the CC and Hub.

37 TR 101 984 V1.2.1 (2007-12) Annex C: etwork interface examples The reference interfaces are shown in figures C.1 and C.2. In these models the satellite radio interfaces are separated into an UpLink (UL) and a DownLink (DL). Figure C.1 shows the interfaces for the case of a satellite return channel and figure C.2 shows the case where the satellite return channel at the User is replaced with a bi-directional hybrid channel that uses terrestrial s to transport all of the return traffic and may also transport some of the forward traffic (e.g. time critical traffic). User payload Gateway User interworking functions Gateway interworking functions T interface radio interface U /DL U /UL satellite payload U GW /UL U GW /DL radio interface External interface G Figure C.1: BSM interfaces: satellite return channel User payload Gateway User interworking functions Gateway interworking functions T interface Hybrid return interface radio interface U /DL satellite payload U GW /UL radio interface Hybrid return interface External interface G H H GW Terrestrial Figure C.2: BSM interfaces: terrestrial return channel Figure C.2. introduces two new reference interfaces for the hybrid return path: H and H GW. These interfaces may either be realized as separate interfaces (e.g. a dial-up modem or ADSL connection at the User ) or may be combined with the External interface (e.g. H GW may be physically combined with the G interface in the Gateway ).

38 TR 101 984 V1.2.1 (2007-12) Annex D: Bibliography TR 101 374-1: " Earth Stations and Systems (SES); Broadband satellite multimedia; Part 1: Survey on standardization objectives".

39 TR 101 984 V1.2.1 (2007-12) History Document history V1.1.1 ovember 2002 Publication V1.2.1 December 2007 Publication