NETWORKING OVER THE IBIS SYSTEM Sergio Chacón(1), José Luis Casas(1), Asís Cal(1), Rafael Rey(1), Josep Prat(1), Javier de la Plaza(1), Gilles Monzat(2), Patrice Carrere(2), Carlos Miguel Nieto(3), Fco. Javier Ruiz Piñar(3) (1)
(2)
ALCATEL ESPACIO, C/ Einstein 7, 28760 Tres Cantos (Spain),
[email protected]
ALCATEL SPACE INDUSTRIES 5, rue Noël-Pons 92737 Nannterre Cedex (France)
[email protected]
ABSTRACT The Integrated Broadcast Interaction System is implemented with a fully regenerative On-Board Processor (Alcatel 9343) designed to provide direct (distributed) DVB-RCS[1] (Digital Video Broadcasting Return Channel Satellite) compliant satellite access for individual digital video broadcasters, Internet Service Providers, and multimedia users. This paper presents the mechanisms which make it possible to support connectionless services over a connection oriented satellite network as well as provide QoS support. I.
INTRODUCTION
IBIS integrates two existing satellite transmission standards: DVB-RCS and DVB-S [2] (Digital Video Broadcasting Satellite). Both of which are used in transparent satellites without any regeneration on board. IBIS combines these two standards into a single regenerative multi-spot satellite system allowing for full cross-connectivity between the different uplink and downlink beams. A9343
DVB-S DOWNLINK #N
TDMA
DVB-RCS UPLINK
DVB-S DOWNLINK #2 FDMA DVB-S DOWNLINK #1
UPLINK COVERAGE #1 DOWNLINK COVERAGE #2
UPLINK COVERAGE #2
DOWNLINK COVERAGE #1
Figure 1: IBIS System Concept The Uplink will be compliant with the DVB-RCS standard. This fact will allow users to use standard RCST (Return Channel Satellite Terminal) stations, which will be widespread and relatively inexpensive in the future thanks to the standardization effort of terminal manufacturers and broadcast satellite
(3)
ETSIT Universidad Politécnica de Madrid, Ciudad Universitaria s/n, 28040 Madrid (Spain),
[email protected]
operators. Individual users and broadcasters will be able to access the satellite on any of several uplink coverage footprints illuminated by the satellite, using multiple frequencies, within a TDMA frame, and at several transmission rates (multiple-rate MF-TDMA or Multiple Frequency Time Division Multiple Access). The Downlink will be fully compliant with the DVB-S Standard, including all the possible convolutional rates [3]. This will allow users to take advantage of the economies of scale and the performance of standard commercial DVB-S receivers, which are widespread across Europe today. A key feature of the system will be the capacity to route data on any of the uplink coverage footprints on to any combination of downlink coverage footprints; the system will implement full cross-connectivity between uplink and downlink footprints. In order to accomplish all this, contributions from all DVB-RCS compliant uplink users must be demultiplexed, demodulated, and decoded and then switched and re-multiplexed into the DVB-S compliant downlink data streams as required by users. On board switching and multiplexing will take place in accordance with a dynamic multiplexer table. Each downlink has associated with it a multiplexing table. It will be possible to reconfigure this table very quickly through a regenerative signaling channel allowing very fast circuit switching at packet level onboard. In case of emergency the standard Telecommand (TM/TC) channel will be used to configure the payload. II.
THE IBIS NETWORKING MODEL
The Communication Model as is defined in the DVBRCS Standard is shown in Figure 2. The Broadcast Channel is defined as a unidirectional channel from the Service Provider to the User, while the Interaction Channel is defined as a bi-directional channel used to exchange information between the Service Provider and the User or between Users.
SATELLITE
Freq.
USER
RCST
MF-TDMA RESOURCE ALLOCATION
Broadcast Ch. time
SERVICE PROVIDER
Service Provider Processing
RCST
Interaction Ch.
USER
RCST Channel_id_3 Channel_id_1
Figure 2:The DVB-RCS Communication Model
RCST
In the IBIS System, both broadcast channel and interaction channel will be DVB-RCS compliant on the uplink and DVB-S compliant on the Downlink. A regenerative signaling channel (see Figure 3) is used for fast configuration of the satellite and general OBP management. It is also used by the Service Provider or the User (in this case they are just users) to communicate with the NCC (Network Control Center). This channel is used for the Logon & Synchronism Procedures, and for resource requests. SATELLITE
Channel_id_2
QoS type A QUEUE
QoS type A QUEUE
QoS type B QUEUE
QoS type B QUEUE
QoS type B QUEUE
QoS type C QUEUE
QoS type C QUEUE
QoS type C QUEUE LAN
D/L #3
QoS type A QUEUE
QUEUING FOR ROUTE #1
D/L #2
D/L #1
QUEUING FOR QUEUING FOR ROUTE #2 ROUTE #3
Figure 4: On Board Packet Level Switching IBIS MF-TDMA resource granularity is such that users can access the satellite using carriers with transmission rates as low as 350 ksym/s (QPSK symbols) within a TDMA frame structure (frame duration is around 69 ms) allowing for resource allocation granularities of one MPEG2-TS packet per frame.
USER
RCST SERVICE PROVIDER
Service Provider Processing
USER
RCST
Signaling Channel
RCST
NETWORK CONTROL
Network Operation
RCST
Figure 3: The IBIS Signaling Channel The basic symmetry among users along with centralized resource management will make the system ideally suited for true mesh networking with a single hop through the satellite combined with the advantages of signaling through a star topology.
Real-time services such as VoIP or Videoconferencing require reduced propagation delay and jitter. The IBIS system MF-TDMA resource granularity is such that real-time services can be supported in an effective and efficient manner. VoIP requires at least one MPEG2TS packet per frame. One MPEG2-TS Packet per frame corresponds to a 21 kbps real-time channel, which can provide a 13 kbps service for the application layer (VoIP) (after removing MPEG/MPE/IP/UDP/ RTP encapsulation). With an 8 kbps CODEC such as the G.729, a 13 kbps channel is about right to absorb the conversation traffic, while leaving resources for best-effort services to be aggregated along with the VoIP conversation. BANDWIDTH ON DEMAND
Multimedia applications require flexible on-board bandwidth resource allocation and packet level switching. Figure 4 illustrates how the multi-beam IBIS system allocates MF-TDMA resources to the different QoS Queues supported by the RCST per destination Downlink. In this example, a four packet (MPEG2-TS) MF-TDMA resource is allocated to an RCST supporting a LAN. The different users on the LAN need to communicate with other users located on different downlinks. The IBIS OBP will be able to route information on a packet by packet basis to the different downlinks as required by the LAN users’ needs. As the needs change, the IBIS OBP switching matrix will change on a real time basis.
B 8 Mbps I T R A 264 kbps T E
Non-Real Time Services
Reduced Jitter Services (Real-Time)
132 kbps
O N
80 kbps 60 kbps
D E 40 kbps M 20 kbps A N D
Figure 5: Bandwidth on Demand A. System Players Service Provider Feeds the system with Broadcast Contents and/or provides an IP-based service. A Video Service Provider
will also supply the NCC with its sections of the MPEG2 tables (partial tables). User In the video world, uses these Broadcast Contents and may reply with answers or requests for the Service Provider. In the IP world, it behaves as a gateway sending and receiving IP information for a number of users attached to the RCTS. Network Control Center The Network Control Center (NCC) centralizes Access and Network management in a system-unique and integrated Network Control Center. Therefore it manages overall OBP configuration, in particular it configures the switching routes on board in accordance with the needs of the various users within the network. OBP management can be done through the Telemetry and Telecommand (TM/TC) channel or through a regenerative signaling channel (similar in format to a regular traffic channel). The NCC is the only entity using this regenerative signaling channel to manage the OBP in real-time. The NCC serves satellite access requests from the various users of the system. The NCC Station manages an entire Interactive Network including all the required DVB-S, DVB-RCS and MPEG2 tables (including coordination of Video Service Provider partial tables). B. Services Two types of services are considered in IBIS: native MPEG based and IP based services. Native MPEG Based Services MPEG Based such as Distributed Digital TV Broadcast, Interactive Digital TV and Tele-shopping. IP Based Services The IBIS network architecture supports unicast and multicast communications between User PCs. A User PC is connected to a LAN which is serviced by a Satellite Terminal (RCST). The Satellite Network supports communications from one Satellite Terminal toward one Satellite Terminal (unicast) and as well toward several Satellite Terminals (multicast). The overall system is based on a layer-3 interconnection scheme (Satellite Terminals act as IP Routers). III. IBIS IP INTERFACE: THE ADAPTATION LAYER The IBIS interface with the IP world is included in the IBIS Adaptation Layer (illustrated in the figure below). On the user plane the interface is at the IP layer. On the Control plane, the IBIS Adaptation Layer provides
support for the possible IP services to be implemented over IBIS. UPPER LAYERS & APPLICATIONS
QoS SUPPORT IBIS TRANSPORT (USER PLANE)
IBIS ADAPTATION LAYER (CONTROL PLANE) ADDRESS RESOLUTION
DVB-RCS
IBIS LOWER LAYERS
IP MULTICAST SUPPORT
CONNECTION CONTROL
DVB-S
Figure 6: The IBIS Interface Diagram IBIS, like DVB-RCS, is connection oriented while IP is connectionless. An adaptation layer is required to provide a mechanism for transmission of datagrams over a connection-oriented network. This Adaptation Layer is located on the Control Plane above the layers specified by the DVB-RCS Standard [1] and is therefore completely in line and compliant with the DVB-RCS standard. In addition, the Adaptation Layer Provides a Mechanism for QoS Provision • Priority Scheduling • Satellite Resource Allocation (Connection Triggering) • Address Resolution (serviced by the Connection Control Protocol) • IP Multicast Support (join, leave, multicast address management) The design and implementation of this adaptation layer is part of the IBIS project. The basic strategy is: • A connection is opened to the node that must receive the datagram if it does not exist. • The datagram is transmitted on the corresponding connection, with some encapsulation. • Connections have activity timers associated to them. The activity timer is restarted every time there is activity on the connection (transmit/receive). If the timer associated to a connection expires, the connection is released. An IP flow is identified by 4 elements: source IP address, source port, destination IP address and destination port. All flows beginning on the same RCST (RCST A) and sent towards the same RCST (RCST B) are grouped into the same connection. In the
same way, all connections from a RCST sent towards the same downlink are grouped with a common channel_ID. All this can be seen more clearly in the following figure: Flow 1 VoIP
IBIS network
Connection From host A to Host B
Flow 2 HTTP 1 Flow 2 HTTP 2
Flow 2 FTP
Private IP network 2 IBIS Connection #2
Channel_ID To downlink X
LAN #1
LAN #2
RCST User
Figure 9: IBIS Network Connections A. Protocol stack
Figure 7: Flow, Connection, and Channel_ID Hierarchy
In IBIS, resources are allocated on a channel_ID basis. According to the traffic requirements, several RCS resource allocation strategies are proposed: Ø Continuous Rate Assignment (CRA) is suitable for carrying traffic with constant rate QoS requirements, or for providing the minimum rate for VBR traffic. Ø Rate, Volume, and Free Capacity based allocations (RBDC/VBDC/AVBDC/FCA) are suitable for carrying traffic with no QoS requirements or the variable part of VBR traffic. In the BIM, only RBDC and FCA will be used supported. Applications deliver traffic to IBIS at IP level. IBIS must then determine how to handle the IP packet. If the destination IP address is already assigned to a connection, the packet will be queued accordingly. If the IP destination address is not associated to an existing connection, IBIS will trigger a new connection to appropriate destination and with the QoS parameters required by the application.
Figure 10 shows the user plane protocol stack in the IBIS system. From the network point of view, IP routing is provided by RCSTs, as well as NAT, DHCP and IGMP functionality. RCST
RCST
IP
IP MPE
Ethernet
MPE
OBP
MPEG2-TS 10/100BT
DVB-RCS
OBP Switch DVB-S
DVB-RCS
DVB-S
Ethernet
MPEG2-TS DVB-RCS
DVB-S
To user
10/100BT
To user
Figure 10: User plane Protocol Stack B. QoS / IP Addressing A private addressing scheme is foreseen for the IBIS network. Since RCSTs act as IP routers, a routing table is available in each one of them. These tables are configured with next-hop IP addresses of any other RSCTs in the IBIS system.
The IBIS system provides QoS support based in current standards such as Diffserv, Intserv or RSVP. IBIS elements providing QoS capabilities (NCC/RCSTs) are located in the ground segment and will evolve towards those IP QoS mechanisms prevailing in terrestrial networks.
IBIS
IP Packet
Where ?
Application
IBIS Connection #1
Private IP network 1
Connection From host A to Host C
Flow 1 HTTP 1
system can be seen as IP routers with a satellite interface. Figure 9 depicts the IBIS network architecture supporting full meshed unicast and multicast communications between users wherever they are located.
New Dest. IP ?
Yes
No Use Established Connection
V.
BW ? Jitter ? Priority ?
Figure 8: The IBIS Interface Connection Triggering
ACCESS LAYER
Two different types of services are provided at access level: • Bi-directional Point-to-Point Connections (RCST to RCST addressing) •
Unidirectional Point-to-Multi-Point Connections (RCST to TS addressing)
IV. NETWORK LAYER
As mentioned, the IBIS system is based on layer 3 interconnections. The RCSTs belonging to the IBIS
Both native MPEG-2 and IP services are supported at access layer level. Connections can be also be classified attending to its triggering method:
• Permanent connections: Pre-configured by management. When the RCSTs logs in the system, these connections are automatically established. Bandwidth as well as QoS parameters are preestablished. Permanent connections are always guaranteed. • On-demand connections: Established by signaling. With these connections the use of IBIS resources is optimized. They allow dynamic bandwidth, QoS parameters modification as well as addition and elimination of members in multicast connections. This type of connections can be rejected at the establishment if not enough network resources are available.
The following Access Layer Transfer Capabilities will be supported: • Reserved Guaranteed Constant Rate (R-GCR) • Unreserved Guaranteed Constant Rate (UGCR) • Un-guaranteed Variable Rate (UVR) The table below summarizes the characteristics of the Access Layer Transfer Capabilities. Access Layer Transfer Capabilities R-GCR U-GCR UVR
Description • • • • • •
Reserved by management Always granted at setup Guaranteed or refused at setup through Connection Control Not guaranteed Initialized by setup/declaration request Potentially modified by Capacity Requests later
Table 1: Access Layer Transfer capabilities
These transfer capabilities will be mapped over the DVB-RCS Standard [1] capabilities: DVB-RCS Resource Request Capabilities CRA RBDC VBDC/AVBDC FCA
Description Constant Rate Assignment Rate Based Dynamic Capacity requests from RCSTs Volume Based Dynamic Capacity requests from RCSTs Free Capacity Assignment
Table 2: DVB-RCS request capacities VI. PHYSICAL LAYER
The IBIS Uplink is compliant with the DVB-RCS Standard MPEG2 Option [1] while the Downlink is compliant with the DVB-S Standard [2].
VII. CONCLUSION
IBIS combines DVB-RCS and DVB-S into a single regenerative multi-spot satellite system allowing for full cross-connectivity between the different uplink and downlink beams. IBIS is implemented with a fully regenerative On-Board Processor (Alcatel 9343) designed to provide direct (distributed) DVB-RCS compliant satellite access for individual digital video broadcasters, Internet Service Providers, and multimedia users. IBIS will provide users with a high capacity dedicated link supporting real-time services on a flexible realtime per-need basis, taking advantage of the inherent satellite broadcast capacity and the OBP’s (Alcatel 9343) full cross-connectivity between uplink and downlink spots. The IBIS OBP will be able to route information on a packet by packet basis to the different downlinks as required by the users’ needs. As the needs change, the IBIS OBP switching matrix will change on a real time basis. The IBIS interface with the IP world is included in the IBIS Adaptation Layer. On the user plane the interface is at the IP layer. On the Control plane, the IBIS Adaptation Layer provides support for the possible IP services to be implemented over IBIS. VIII. REFERENCES
[1] EN 301 790, DVB Interaction channel for satellite distribution systems, ver 1.2.2, ETSI [2] EN 301 192, DVB specification for data broadcasting, ver 1.2.1, ETSI [3] EN 300 421, DVB Framing structure, channel coding and modulation 11/12 Ghz satellite services, ver 1.1.2, ETSI [4] EN 300 468, DVB Specification for Service Information (SI) in DVB systems, ver 1.4.1, ETSI [5] M. Lamarca et al., “DVB-Forward: A Digital Television / Internet Payload,” 19th International Communications Satellite Systems Conference and Exhibit, American Institute of Aeronautics and Astronautics, Toulouse, France, 17-20 April 2001. [6] Y. Le Roy et al., “The Alcatel 9343 DVB-OBP Product: An On-Board Processor for Digital Television and Internet Data,” Seventh International Workshop on Digital Signal Processing Techniques for Space Communications, Sesimbra, Portugal, , 1-3 October 2001. [7] S. Chacón et al., “Multimedia Applications of the Integrated Broadcast Interaction System”, Seventh International Workshop on Digital Signal Processing Techniques for Space Communications, Sesimbra, Portugal, , 1-3 October 2001.
