Chapter 1: INTRODUCTION TO SATELLITE COMMUNICATIONS 27 Fig. 1.8: The four possible DVB-S2 constellations before physical layer scrambling. 1.4.5 Numerical details on the selected scenarios for performance evaluations This sub-Section provides some basic characteristics and numeric values for the parameters that have been used when evaluating the performance of the techniques proposed in the following Chapters of this book for the different scenarios. The details are provided below. Scenario 1: S-UMTS as well as S-HSDPA • GEO satellite • Multi-spot-beam satellite antenna • Bent-pipe satellite • Terrestrial gateway containing the scheduler (MAC layer) • Direct return link via satellite for channel quality measurements in case of point-to-point services • Mobile users (mean speed equal to 60 km/h) • GOOD-BAD Markov channel model (typically, 6 s mean GOOD duration and 2 s mean BAD duration) [29] • IP-based traffic flows with UMTS transport layer encapsulation • Traffic sources: video sources (sum of ON/OFF Markovian sources) [30] and Web sources (2-MMPP arrival process of Pareto-distributed data- grams) [31]. 28 Giovanni Giambene Scenario 2: DVB-S/DVB-RCS • GEO satellite • Single beam or multi-spot-beam satellite antenna • Bent-pipe satellite • Architecture involving an NCC and at least a GW • Fixed users • Direct return link for channel quality measurements; typically, Ka band is used (maximum capacity 2 Mbit/s) • Forward link in K band • Channel model: only troposphere effects (rain scintillation and gas) have to be considered. Basically an Additive White Gaussian Noise (AWGN) model has been adopted with a given packet error rate (uncorrelated losses) • IP-based traffic flows with MPE encapsulation and generation of packets according to the MPEG2-TS format • Traffic sources of the FTP type (elephant TCP connections). Scenario 3: LEO constellation • A Teledesic-like LEO system (the Boeing design with 288 satellites): altitude of 1375 km, and satellite capacity of 32 Mbit/s • Multi-spot-beam satellite antenna • End-users must switch from spot-beam to spot-beam and from satellite to satellite, resulting in frequent intra- and inter-satellite handovers • We assume a two-dimensional mobility model: users move in straight lines and at constant speed (satellite ground track speed composed with the Earth rotation speed) • All the spot-beam footprints are identical in shape and size (approximated by rectangles, 1790 km × 1790 km) • Traffic assumptions (study made in Chapter 8, Section 8.6): non-real-time traffic for email or FTP and real-time multimedia traffic, e.g., interactive voice and video applications. For each class: (i) new calls arrive in the foot- prints according to independent Poisson processes; (ii) call holding times are exponentially distributed. Within each traffic class, three different user types are considered that are differentiated depending on the call holding time and bit-rates. 1.5 Satellite networks A satellite network can play several roles [32]. In particular, it can be used as Access Network for final users or it can be part of the Core Network. Some examples are shown in Figure 1.9. The ETSI TC-SES/BSM (Satellite Earth Stations and Systems / Broad- band Satellite Multimedia) working group had the task to focus on IP layer Chapter 1: INTRODUCTION TO SATELLITE COMMUNICATIONS 29 Fig. 1.9: Examples for the use of satellite links in telecommunication networks. interworking, to define a new network architecture and to include alternative families of lower layer air interfaces [33]. A Broadband Satellite Multimedia (BSM) network is divided into 5 domains, as specified in ETSI TR 101 984 [32]: • User Domain, representing the group of end-users; • Access Domain that denotes the access network that is used to connect to the service provider (e.g., ADSL, UMTS, satellite); • Distribution Network : this is an intermediate network that is interposed between the access network and the core network; • Core Network, representing the backbone transport network that is used to connect the routers on a geographical area; • Content Domain that represents the area where contents and information are stored to be made available to users. The user requesting contents should access them feeling like as he/she was directly connected to the source of the information, the Content Domain; practically, many domains are traversed that are transparent to the user. Let us now consider the BSM network functions from the protocol stack standpoint (see Figure 1.10) that can involve different layers, as specified in ETSI TR 101 985 [34]: • The BSM network operates at layer 2, like a bridge. • The BSM network operates at layer 3, so that the satellite Earth stations are routers. • The BSM network operates at a layer above the 3 rd one: the satellite Earth stations are gateways. In this case, these stations can perform a more accurate routing based not only on the IP datagram header, but also on information of higher layer headers. In such a case, the Earth station can implement special functions, like Performance Enhancing Proxies (PEPs) 30 Giovanni Giambene that are important in order to improve the TCP performance in satellite networks. Fig. 1.10: BSM general network architecture. Very Small Aperture Terminal (VSAT) networks are a special case of BSM networks where the user terminal employs a small antenna (i.e., VSAT) and simplified equipment so as to reduce costs. This small satellite terminal can be used for one way and/or interactive communications. VSATs can support several applications, such as: satellite news gathering, supervisory control and data acquisition, inquiry/response, TV and audio broadcasting, data distribution. VSAT networks are based on GEO satellites (typically of the bent-pipe type) according to a star topology: an Earth station acts as a hub (= gateway to the terrestrial network and master control station), receiving and transmitting all the data fluxes from/to VSATs. The forward link (from the hub to VSATs) is via GEO satellite. The return link (from VSAT to the hub) is typically via a terrestrial Public Switched Telephone Network (PSTN) link (to simplify the antenna design on the VSAT). Hence, forward and return links have an asymmetrical capacity; anyway recent advances in this field also allow the return link via satellite. Referring to the network architecture in Figure 1.10, the VSAT includes the client and the Earth station on the left; whereas, the hub coincides with the Earth station on the right. Different VSAT platforms use various technologies in order to access the satellite radio space segment and to share it among multiple users. One of the problems that VSAT networks have faced during their evolution has been the lack of compliance to any specific standards. In the last years, standardization bodies have established new standards to support satellite Internet [23]. The DVB standard has been the first one to be published, and ETSI adopted DVB-RCS for satellite return link transmissions. Another standard is IPoS (Internet Protocol over Satellite) developed by HNS (Hughes Network Systems)and Chapter 1: INTRODUCTION TO SATELLITE COMMUNICATIONS 31 standardized by ETSI. Finally, DOCSIS-S (Data Over Cable Service Interface Specification for Satellite), a modification to the DOCSIS cable-modem has been proposed for adapting it to the transmissions over satellite. Let us focus on satellite IP networks. The ETSI TC-SES/BSM working group has defined the protocol stack architecture shown in Figure 1.11 where lower layers depend on satellite system implementation (Satellite-Dependent, SD, layers) and higher layers are those typical of the Internet protocol stack (Satellite-Independent, SI, layers). These two blocks of stacked protocols are interconnected through the SI-SAP (Satellite-Independent - Service Access Point) interface. Only a small number of generic functions need to cross the SI-SAP; in particular: address resolution, resource management, traffic classes QoS. The SI-SAP interface is logically divided into three SAPs, each of them with a suitable function and security characteristics, as described in the ETSI TS 102 465 standard [35]. In particular, we have: • SI-U-SAP (User-SAP): transfer of IP packets between the users; • SI-C-SAP (Control-SAP ): transfer of control data and of service signaling for SI-U-SAP; • SI-M-SAP (Management-SAP): transfer of management information. The protocol stack organization defined by TC-SES/BSM (see Figure 1.11) has been taken as the basis for the organization of the work in this book, where after a first part with introductory concepts, the second part deals with SD layers and the third part focuses on SI protocol layers. More details on the BSM protocol stack are provided in the following sub-Section. 1.5.1 SI-SAP interface overview SI-SAP defines an interface between SI upper layers and SD lower layers, that applies to all air interface families for satellite communication systems [32],[34]. SI-SAPs correspond to the endpoints of BSM bearer services. SI-SAP is used to define standard SI bearer services that are built upon lower layer transmission services. Point-to-point, point-to-multipoint, multipoint- to-multipoint and broadcast bearer services are defined as the edge-to-edge services provided by the BSM sub-network. SI-SAP provides an abstract interface allowing BSM protocols (BSM address resolution, BSM resource management, etc.) to perform over any BSM family (i.e., layer 1 and 2 technology) [33]. For traffic handling purposes, SI-SAP uses a BSM Identifier (BSM ID) and Queuing Identifiers (QIDs): • The BSM ID uniquely identifies a BSM network point of attachment and allows IP layer address resolution protocols (equivalent to Address Resolution Protocol,ARPforIPv4andNeighbor Discovery,NDforIPv6) to be used over the BSM. 32 Giovanni Giambene Fig. 1.11: Standardized protocol stack. • QIDs are abstract queues (SI-SAP level) that represent the layer 2 queues in a general way to allow the mapping with layer 3 ones (note that using a QoS support mechanism at layer 3, different queues are needed). QIDs are a way to hide specific SD layer implementations (i.e., BSM technology) from the IP layer. Each QID queue is characterized by QoS-specific parameters (flowspecs, path label or Differentiated Service, DiffServ, marking) and is associated to lower layer transfer capabilities (i.e., capacity allocation methods) and buffer management policies [36]. The SD layers are responsible for assigning satellite capacity to these abstract queues (e.g., in DVB-RCS we can consider the allocation methods such as CRA, VBDC, etc., and combinations of them). The mapping of IP queues to QIDs is flexible: there is no strict constraint for a one-to-one mapping, but we may also consider that more IP queues correspond to the same QID (in this case, a scheduler should be used at layer 3 to determine the service order of the different queues to be mapped to the same QID). BSM networks use a suitable and general categorization of traffic flows in traffic classes that can be mapped to classical IP QoS classes [25]. In particular, 8 traffic classes, i.e., service priority levels, are defined from 0 for emergency services to 7 for low priority broadcast/multicast traffic. Other functional blocks are involved in the management of the queues in BSM protocol architecture; the interested reader may refer to [36]. All the BSM services (data transfer, address management, group adver- Chapter 1: INTRODUCTION TO SATELLITE COMMUNICATIONS 33 tisement, etc.) use SI-SAP primitives [37]. These primitives are classified into functional groups within the User plane (U), Control plane (C) and Management plane (M). The primitives (exchanged between the upper layers and the lower layers) are of the following four types: • The REQUEST primitive type is used when the SI layer is requesting a service from the SD layer. • The INDICATION primitive type is used by the SD layer to notify the SI layer of activities. This type may either be related to a REQUEST type at the peer entity, or may be an indication of an unsolicited lower layer event. • The RESPONSE primitive type is used by the SI layer to acknowledge the receipt of the INDICATION type from the SD layer. • The CONFIRM primitive type is used by the SD layer to confirm that the activity requested by a previous REQUEST primitive has been completed. The services provided at the SI-SAP level are divided into functional groups for U-, C-, and M-plane, as described below [37]. Each service uses one or more different types of the above-mentioned primitives. • U-plane services – Data Transfer: These services are used to send and receive user data via the SI-SAP. Data transfer services can be used for both unicast and multicast data transfer. • C-plane services – Address Resolution: A mechanism to associate a BSM ID address to a given IPv4 unicast or multicast address. A successful address resolution service returns the associated BSM ID. The BSM ID can be either a Unicast ID for unicast services or a Group ID for multicast services. – Resource Reservation: These services are used to open, modify and close SD layer queues (for both unicast and multicast flows) to be used by SI layers. This function assigns the QID and defines or modifies the properties of the abstract queue that is associated with that QID. Resource reservation is required only for sending data (not for receiving data). – Group Receive/Send: They are mechanisms to activate and configure the SD layers to receive/send a needed multicast service. These services are used to associate a multicast group address (e.g., an IPv4 Class D address, or an IPv6 multicast address) with a series of SD parameters. – Flow Control: These primitives allow activating and adjusting the SD layers to provide SI-SAP flow control for a specific QID (i.e., on one or more of the SD layer queues). • M-plane services – At present, no M-plane services are defined in the standard. 34 Giovanni Giambene 1.6 Novel approaches for satellite networks The increasing demand for multimedia broadband services and high-speed Internet access via satellite requires the definition of an optimized satellite protocol stack as well as the full integration of the satellite network with terrestrial ones. Consequently, two innovative approaches are at present conceived [38], namely horizontal approach and vertical approach. 1.6.1 Horizontal approach We expect that different wireless technologies (e.g., wireless local area net- works, cellular systems, satellite networks) need to co-operate to allow the best radio coverage to the users, depending on their locations, mobility characteristics, applications, user profile, etc. This is in accordance with the Always Best Connected (ABC) paradigm. Therefore, it is necessary that the use of the resources in the different Radio Access Networks (RANs) be globally coordinated by means of a resource brokerage function. Such intelligence is centralized and allocates sessions to RANs or switches them from one to another, when some conditions are meet. 1.6.2 Vertical approach The ISO/OSI reference model and the Internet protocol suite are based on a layering paradigm. Each protocol solves a specific problem by using the services provided by modules below it and gives a new service to upper layers. The disadvantages of such approach can be detailed as follows: • The needs of a service provided by the communication system to its users are defined at the top-level, but the hierarchy and the overall system performance are built upon the bottom-level. • The bottom level does not communicate directly, but through intermediate layers with the top-level. Information is lost during this layer-by-layer top- down conversion. • Layers are independently optimized. However, in many cases, the close interaction among them should be considered. A strict modularity and layer independence may lead to non-optimal performance in IP-based next-generation satellite communication systems. Finally, since both radio and power resources are strongly constrained on the satellite, a protocol optimization is mandatory. Such optimization requires a vertical design of the air interface protocol stack. Such cross-layer approach entails new interfaces across the layers, which exchange control information beyond the standard ISO/OSI structure. Cross-layer interfaces can be between or beyond adjacent protocol layers. Although interfaces between adjacent layers are in general preferable, there can be the need for efficient and direct in- teractions between non-adjacent layers [39]; in general, a layer should be aware Chapter 1: INTRODUCTION TO SATELLITE COMMUNICATIONS 35 of the internal state of the other layers of the protocol stack. For instance, OSI layer 3 (e.g., IP) and above often need direct interfaces to OSI layer 2, e.g., for handover support. Another example concerns transmission parameters (e.g., transmission mode, channel coding and persistency degree for link layer retransmissions) that must be related to application characteristics (e.g., type of information, source coding, etc.), network characteristics, user preferences and context of use. Finally, lower layers (i.e., 1 and 2) should be aware of higher layer (i.e., 3 and 4) behaviors in order to take appropriate decisions on traffic management. Cross-layer methods can be classified into two broad groups as follows: • Implicit cross-layer design: there is no exchange of signaling among differ- ent layers during operation, but in the design phase cross-layer interactions are taken into consideration for a joint optimization. • Explicit cross-layer design: signaling interactions among (non-)adjacent protocol levels are employed so that the internal state of a protocol can be made available to the protocols at different layers for dynamic adaptations. The above distinction of methods is at the basis of all the different cross-layer schemes presented in the following Chapters of this book. As for explicit cross-layer methods, new interfaces are needed beyond adja- cent layers. Different solutions have been proposed to support the cross-layer exchange of signaling information; an interesting method has emerged from the following papers [40]-[43], where a ‘global coordinator’ of the different layers is considered allowing to acquire status information from the different protocols to store it in a shared memory and to set the internal state of the protocols to be adaptable to different events. A possible implementation of the global coordinator could be to exploit the capabilities of the management plane of the protocol stack that can interact and coordinate the different layers. The management plane could exploit the control service access points between layers to send control broadcast signaling to all the layers for their respective actions. More details on these aspects are provided in Chapter 4. Finally, referring to the ETSI TC-SES/BSM protocol stack architecture shown in Figure 1.11, it is important to note here that the cross-layer methods involving SD and SI layers will require the adoption of suitable primitives crossing the SI-SAP interface. In order to explain BSM cross-layer interactions and their relations to SI-SAP, some examples are proposed below for both implicit and explicit cross-layer design cases. BSM Protocol Manager The BSM Protocol Manager (BPM) has been conceived in the BSM protocol stack to maintain QoS and evaluate the BSM performance [44]. BPM resides above the SI-SAP and defines how IP protocols and packet markings are interpreted and transmitted through the BSM, which SI protocols are used 36 Giovanni Giambene and how they in turn trigger the SD functions (see Figure 1.12). BPM has interfaces at different levels of the BSM protocol stack. In particular, BPM interacts with a specific middleware to establish transport level and application level PEPs, communicates with bandwidth brokers and potentially with service discovery and security/authentication functions. BPM directly interacts with IP protocols, including Multiprotocol Label Switching (MPLS) for route discovery and Integrated Service (IntServ) or Differentiated Service (DiffServ) models (see Chapter 8, Section 8.2, for more details). For all these reasons the BPM could represent a viable solution to implement the so-called ‘global coordinator’ (explicit cross-layer approach design). In such a case suitable primitives should be designed to support cross-layer signaling through the C-plane. Fig. 1.12: Protocol manager and BSM protocol architecture [44]. Implicit cross-layer design examples An example of implicit cross-layer (i.e., joint protocol design/optimization) could be PHY layer adaptation in the presence of ACM with thresholds between modes that have been selected to optimize the transport layer performance [39]. Explicit cross-layer design examples It is possible to distinguish between explicit cross-layer involving layers across SI-SAP or involving layers in SD or SI. . Multi-spot-beam satellite antenna • Bent-pipe satellite • Terrestrial gateway containing the scheduler (MAC layer) • Direct return link via satellite for channel quality measurements in case of point-to-point. and satellite capacity of 32 Mbit/s • Multi-spot-beam satellite antenna • End-users must switch from spot-beam to spot-beam and from satellite to satellite, resulting in frequent intra- and inter -satellite. the Internet protocol stack (Satellite- Independent, SI, layers). These two blocks of stacked protocols are interconnected through the SI-SAP (Satellite- Independent - Service Access Point) interface.