Multicast and broadcast support in AeroMACS

Transcription

1 EUROCONTROL AeroMACS Technical Support Version: Working draft Multicast and broadcast support in AeroMACS Note Identifier: Author Elaboration date: AT4_ECTL_TN#18 AT4 wireless (under contract with EUROCONTROL) ALOT Technologies (under contract with EUROCONTROL) dd23 Sources: [1] RFC 2460 IETF [2] IEEE Std IEEE [3] WMF-T R010v04-Stage2 WiMAX Forum [4] RFC 3315 IETF [5] RFC 4862 IETF [6] AeroMACS PICS [7] SESAR D1.1 Profile Analysis [8] SESAR D2.2 Traffic Modeling [9] AeroMACS MASPS WiMAX Forum SJU SJU EUROCAE IMPORTANT: No parts of this technical note may be reproduced or quoted out of context, in any form or by any means, except in full, without the previous written permission of EUROCONTROL AT4 wireless S.A Page 1 of

2 1. Current situation of multicast/broadcast in AeroMACS standards The IEEE specifies two ways to implement broadcast/multicast services at MAC layer level: Multicast and Broadcast Services (MBS) and Multicast transport connection (CID sharing). Additionally, in order to enforce security in the second mechanism, one additional SA (Security Association) will be shared by multiple MSs and the broadcasting BS. This type of SA is called GSA (Group SA). The following table summarizes the current situation of multicast/broadcast in all standards: MBS Multicast traffic connections GSA IEEE WF System Profile WF PICS WF test cases available WF CRSL AeroMACS Profile MOPS System Explicitly mentioned as optional in the standard or is not explicitly mentioned but has capability negotiations. It may or may not be implemented. The item is not required to get general WiMAX certified label and Is required to get distinct WiMAX certified with MBS capability label. Y (PCT) Y (MIOT) Mandatory Not required by WiMAX certification N Not required N Y N The sections are not applicable to AeroMACS and hence are not requirements on the implementation. MASPS Section 3 ASN Gateway functionalities: No Multicast/Broadcast Control Module (MBS). Not referred N The source of there references noted in the table above have been extracted from the standards in Annex 1. AT4 wireless S.A Page 2 of 22

3 2. Proposal to implement broadcast / multicast in AeroMACS A proposal for a way to implement broadcast and multicast according to the current provisions in the profile and MOPS is given in this section. Note that, in this document, broadcast / multicast capability refers to functionalities that take advantage of the PMP (point to multipoint) operation of AeroMACS link to use efficiently the radio resources by transmitting the same data payload from a BS to different MS in a single multicast message (as opposed to transmitting the same information to each MS in different unicast messages). This is independent from the operation of IP multicast and broadcast or the execution of multicast and broadcast services. The two latter can be transported over an AeroMACS data link even if the multicast / broadcast capability is not supported. Also note that, due to the PMP nature of AeroMACS data link, multicast /broadcast connections are only provisioned in the DL (from BS to MS direction). If an MBS service data is generated by an aircraft or vehicle, the MS cannot simply broadcast it in an AeroMACS channel, it will need to be sent uplink it to the server which then multicasts / broadcasts the message to all the MS in the group. The list below indicates the potential MBS services envisaged to be transported over AeroMACS [7]: Flight Information Services (D-ATIS, D-OTIS, D-RVR, D-SIG, D-SIGMET) TIS-B NOTAM Graphical weather information (WXGRAPH) Airport delay information Broadcast weather information via SWIM SURV An estimation of the amount of data generated by specific services can be worked out from the analysis made in the service modelling list referenced within [8]. Using the number of messages per dialogue and the size of these numbers, together with the maximum service latency, the average data rate (in bps) can be derived in order to comply with the latency figure. An estimation on the peak data load generated by the ATC multicast services operated by a single aircraft ranges from 1 to 9 kbps [8]. On the other side, an AOC multicast service would be expected to transmit a heavier load of data. The only available example of a computation of the expected data rate generated by an AOC multicast service has been done with WXGRAPH [8]. No estimation has been made available so far of potential multicast services generated by SWIM. AT4 wireless S.A Page 3 of 22

4 The table below depicts the required bandwidth at an airport operating AeroMACS considering the potential air operation scenarios presented in the MASPS [9]. The table indicates the expected peak data rate (i.e. if all the present A/C operate the service simultaneously) per cell. It can be observed that an AeroMACS deployment can well cope with ATC multicast services. However, when multicast AOC services are also enabled, the benefit of operating multicast connections becomes relevant. Operations/hour per airport Assumption of number of simultaneous A/C per airport Assumption of number of BS (cells, i.e. sectors) deployed in airport Assumption of number of MS in cell Estimated peak traffic generated per cell by ATC multicast services [kbps] Unicast Multi cast Estimated peak traffic generated per cell by WXGRAPH [kbps] Unicast Multi cast Multicast feature will provide the following gain to the system capacity: Multicast Gain [kbps] = (Multicast services estimated load [kbps]) * (Number of simultaneous MS in the same cell sector - 1) Accordingly, the Multicast Gain in kbps and % relative to the DL worst case (QPSK1/2: 1.8 Mbps) and best case (64 QAM: 9.1 Mbps) can be estimated from the data in the table above: Airport size ATC multicast services [kbps] WXGRAPH [kbps] Unicast Multicast Gain Gain (%) Gain Gain (%) (kbps) Unicast Multicast worst best (kbps) worst best The possible options to support multicast / broadcast according to the IEEE standard and the AeroMACS Profile and MOPS are shown in the Table below. The best option depends on the type and volume of multicast / broadcast services (MBS) to be transported over the data link, and the level of security required for these services. Multicast option Security on multicast connections Yes No AT4 wireless S.A Page 4 of 22

5 No N/A Unicast MBS MBS with MBSGSA MBS with either: - No authorization policy - SA with No encryption cryptographic suite Multicast group service Multicast traffic connection with GSA Multicast traffic connection with either: - No authorization policy - SA with No encryption cryptographic suite Unicast If this option is followed, all multicast and broadcast services are transmitted over unicast messages on the AeroMACS data link. The CID establishment, traffic classification and QoS rules for incoming traffic are applied the same way as the rest of the service flows. This option requires no support of any additional item, nor any additional test case. The AeroMACS Profile multicast transport connection item may be set to N. This option is acceptable as far as the amount of traffic generated by the network due the transmission of MBS services is small. Note that this does not depend on the number of receiving MS, only on the service load, however the impact on the data transmitted over the radio grows multiplicatively with the number of MS in the cell. The services identified so far as multicast and broadcast are in the order of hundreds of kbps per cell, at most. However, if in the future traffic load due to MBS is expected to be much higher (in the order of Mbps) it may have an impact on the data link performance depending on the QoS policy applied to the service flows (SF) transporting MBS services: a) If configured as Best Effort (BE) or non real time Polling Service (nrtps): The transmission of MBS services may suffer from higher latency. b) If configured as real time Polling Service (rtps): These services may produce higher latency in transmission of other BE or nrtps service flows, which do not have QoS parameters for maximum latency. c) If configured as rtps or nrtps: The aggregate Minimum reserved bandwidth for connections transporting MBS services adds up to the total reserved bandwidth in the cell. If the reserved bandwidth per connection or the number of established connections for MBS services is high, it may limit the bandwidth available for incoming connections, or to be used by other active connections, producing additional delays to other service flows. MBS with MBSGSA AT4 wireless S.A Page 5 of 22

6 MBS is an efficient method to concurrently transport DL data common to a group of MS (called multicast group). Service flows and multicast CIDs transmitting MBS flows are instantiated by a BS or group of BS (called a BS zone) and the registered MS belonging to the multicast group learn from them. The existence of BS zones allows for the provision of Macro Diversity. If a multicast CID is encrypted, it requires the establishment of a MBS group security association (MBSGSA) per multicast CID to maintain the MBS key material (MAK, MGTEK and MTK). MBSGSAs are shared between the BS in the same MBS zone. This option requires the support of a large number of items such as MBS MAP IE and management of MBSGSA multicast keys. Since these items are currently not mandated by the [6], no test cases exist and they are not supported by current COTS products, this option is not recommended due to its high cost. The option of MBS without security is not investigated in this study. Multicast traffic connection with GSA [2] para indicates the possibility to support multicast connections without the need to support MBS and multicast CID. The BS establishes separately a transport connection with each MS in the multicast group by using the same CID. In this manner, the authorized MS will listen to the same channel in the DL frame and access the multicast/broadcast data payload. From the MS point of view, the CID is treated as a unicast connection. From the BS point of view, it is also treated as a unicast connection with the exception that classification rules need to be configured to transmit multicast messages over the common CID. Since each connection is associated with a service flow, it is associated with the QoS parameters of that service flow. ARQ is not applicable. If the DL multicast connection is encrypted, it requires the use of a Group Security Association (GSA) to maintain group key information. During PKMv2 handshake, the GKEK is randomly generated once and distributed to the BSs via the ASN-GW (according to Profile C), and then transmitted to each MS encrypted with each corresponding KEK. The same GTEK is thus derived for all the MSs belonging to the multicast group and encrypted with the GKEK. This option would be required if the majority of the MBS services to be transported over multicast connections need to support MAC security (in addition to already existing service and network security protocols). This could be the case of some flight information services such as TIS-B, or future SWIM services, but no requirement currently exists. This option would require the support of Multicast traffic connection item and Group multicast service SA item, plus the development of corresponding test cases. For the sake of interoperability, it is required that the allowed set of CID(s) is fixed globally. This would need a requirement or guidance material (depending on the intended level of mandate) in the MOPS and ICAO SARPs or Technical Manual. In addition, functionality will need to be provisioned in the ASN-GW to distribute the group key GKEK to the BSs and also the GTEK context during HO procedure, in order to support HO optimization item Skip TEK establishment phase. AT4 wireless S.A Page 6 of 22

7 Multicast traffic connection without security This option follows the multicast connection item as explained in the previous section based on [2] para , without the need to encrypt the multicast connections and manage key information. NOTE: This option would require an assessment to conclude if it is acceptable regarding the secure nature of safety of flight and regularity of life messages. The content of multicast services is often informative and public, so this option is intended for services that do not require security at radio level and device authentication, such as weather reports, NOTAM and flight information services. In the case of aeronautical information from ATC (e.g. TIS-B, FIS-B), it should be analyzed whether the service security at higher layers is sufficient. In any case, the level of security required for new multicast services generated by SWIM needs to be addressed. This approach can be followed by implementing an authorization policy (for the BS-MS pair) or a cryptographic suite (for the SA) not supporting security features. a) Authorization policy is exchanged per BS and MS pair during network entry (or reentry). The MS informs the BS about the types of authorization policy supported during negotiation phase (SBC-REQ/RSP message exchange). The Table below depicts the authorization policies supported by the AeroMACS Profile. If No Authorization is selected as the authorization policy, no key exchange, authentication or encryption is performed with this MS. Null SAID is used by default for all the connections. This solution avoids the necessity to perform authorization and encryption but affects all the transport connections established with a given MS. Thus, it is not acceptable since it precludes unicast connections from being secured. b) Cryptographic suites are the combinations of mechanisms for encryption, data authentication and TEK exchange, and are specific to SA. During the authorization exchange (except if No Authorization policy is chosen), the BS sends the MS a list of SA Descriptors informing about the cryptographic suites used by the static SAs that are active. During Dynamic Service Addition (DSA), SAID is mapped to a given SFID. Table 125 below depicts the cryptographic suites supported by the AeroMACS Profile. [2] does not preclude a BS-MS having different SA active, of which some use key exchange, encryption and data authentication, and some do not, if the BS is configured to support both types of static SA. Thus, it is recommended for the support of unsecure multicast connections that each BS configures a static CID well known to all MS participating in the multicast group. Upon network entry, the CID and associated SFID AT4 wireless S.A Page 7 of 22

8 are established, and a corresponding SA supporting no security is activated and associated to this CID/SFID. Note that it must be a unicast SA, meaning that it is established independently with each MS. However, since the data is sent in plain, all the MS should be able to decode the received data. This mechanism is compatible with HO optimization. When an MS performs handover, the target BS should already possess the security context of the multicast CIDs, so it does not need to perform MS reentry. This is valid for services that do not require security at radio level and device authentication, such as weather reports, NOTAM and flight information services. This option requires the support of multicast traffic connection item and the support of No data encryption [ ] cryptographic suite. It is NOT required to support No authorization policy. To make multicast function operate in every AeroMACS ASN, it is required that the allowed set of CID(s) is fixed globally. This would need guidance material in ICAO Technical Manual. Figure 1 depicts the message exchange during a normal network entry involving the creation of secured unicast DL/UL traffic connections and unsecured multicast DL traffic connections. Note that the unsecured multicast CID3 needs to be the same for all the MS connected to the same BS, however the SAID is created independently per MS. AT4 wireless S.A Page 8 of 22

9 MS1 DL channel acquisition, MAC synchronization (DL-MAP) and obtaining UL channel parameters BS Initial Ranging and PHY adjustments process (RNG-REQ/RSP) SBC-REQ (EAP based authorization) SBC-RSP EAP Request EAP Success PKMv2 (SA-TEK-Challenge) PKMv2 (SA-TEK-Request) PKMv2 (SA-TEK-Response / SAID1 = Crypto suite T125, I6 SAID2 = Crypto suite T125, I1) PKMv2 (Key-Request / SAID1) PKMv2 (Key-Reply / SAID1) EAP based authorization for unicast based communications being further secured The MS gets authenticated in the network and the security context is created SAID1 = Primary SA to be used by secure unicast connections SAID2 = Static SA with cryptographic suite set to no encryption to be used by multicast connections MS acquires the valid TEK keys for SAID1 Registration DL SF creation (Target SAID = SAID1, CID1) UL SF creation (Target SAID = SAID1, CID2) DL SF creation (Target SAID = SAID2, CID3) Establishment of secured (SAID1) unicast connections (CID1 and CID2) Establishment of unsecured (SAID2) multicast connections (CID3) MS2 Same procedure that MS1 DL SF creation (Target SAID = SAID3, CID4) UL SF creation (Target SAID = SAID3, CID5) MS1 and MS2 shares unsecured CID3 multicast channel identifier DL SF creation (Target SAID = SAID4, CID3) Figure 1: How to establish secure unicast and unsecured multicast connections in AeroMACS AT4 wireless S.A Page 9 of 22

10 3. AeroMACS standards evolution to support broadcast / multicast This section proposes a potential evolution on the support of MBS services. The approach involves a cost-efficient manner to leverage the current support of multicast function by standards and COTS products, and includes a potential roadmap to progressively add the support to other aspects of multicast in the future, depending on the industry needs, by using realistic, cost-efficient options identified in previous sections of the document. The evolution addresses the impact on the following aspects of MBS support: - WiMAX Forum Profile and test cases: This includes the support to specific items in AeroMACS Profile and the related WiMAX Forum certification procedures, i.e. the definition of test cases in the AeroMACS PICS and CRSL documentation. - Aviation Standards: This includes the support of MBS related functions in the AeroMACS standards developed by the aviation community, i.e. EUROCAE/RTCA MOPS, ICAO SARPs and Technical Manual, and EUROCAE MASPS. - Operational Requirements: This specifies the requirements that need to be followed in terms of service provision when enabling MBS services on AeroMACS, depending on the evolution phase. NOTE. All options require device authentication, 1 st step: Multicast and broadcast BS services at upper layers over unicast connections This step will follow the Unicast option presented in this document. WiMAX Forum Profile and test cases: Requires no change in AeroMACS Profile. No new test cases are needed. Aviation Standards: No change is required in the MOPS and SARPs. Guidance material included in this paper should be inserted in the ICAO Technical Manual, for this and future evolution phases. End-to-end test cases may be developed in the MASPS based on unicast connection. Operational Requirements: Limitations should be placed, e.g. in the MASPS Operational Requirements section, for the maximum MBS service load being transmitted over AeroMACS in this phase to ensure the performance of the networks is not jeopardized. 2 nd step: Support of not encrypted unsecure multicast connections This step will follow the Multicast traffic connection without security option presented in this document. WiMAX Forum Profile and test cases: No change is required to support the related items 91.1 multicast traffic connection and No authentication etc cryptographic suite, as both are currently set to Y. On the other side, test cases do not exist at this moment and should be developed in the PICS and CRSL. AT4 wireless S.A Page 10 of 22

11 Aviation Standards: No change is required in the MOPS, since the document reflects the minimum performance option. It is neither required in the SARPs since the MBS support is required at service layer. End-to-end test cases over unsecured multicast connection may be developed in the MASPS. Operational Requirements: A comprehensive study should be carried out to select the eligible services that may be enabled by an unsecure multicast connection. Limitations should be specified, e.g. in the Operational Requirements section in the MASPS, on the type of services authorized to be provided over multicast traffic connection. 3 rd step: Support of encrypted secure multicast connections WiMAX Forum Profile and test cases: A profile modification is required to support Group multicast service SA and MBRA for Group multicast service in AeroMACS Profile, as both are currently set to N. Test cases for these new items should be developed in the PICS and CRSL. Aviation Standards: No change is required in the MOPS, since the document reflects the minimum performance option. It is neither required in the SARPs since the MBS support is required at service layer. End-to-end test cases over secure multicast connection may be developed in the MASPS. Operational Requirements: No limitation on the amount or type of MBS services is imposed if this option is implemented AT4 wireless S.A Page 11 of 22

12 Annex 1. Multicast/broadcast standards source WiMAX Forum System Profile AT4 wireless S.A Page 12 of 22

13 WiMAX Forum PICS AT4 wireless S.A Page 13 of 22

14 WiMAX Forum PCT TSS&TP [empty section] AT4 wireless S.A Page 14 of 22

15 RTCA MOPS AT4 wireless S.A Page 15 of 22

16 AeroMACS System Profile: 91 1 Multicast connection traffic Y Y Y MBS is not certifiable by the WMF at publication time of the present document. The alternative mechanism of providing multicast and broadcast services based on sharing a transport CID among MSs is not certified either, but it is the preferred solution./ [3] 112 1, 5, 7 Basic MBS IO-MBS N N Multicast services may be implemented utilizing the Multicast Traffic Connection Feature There is no need for Multicast group management, and therefore the MBS features are not required./ [3] Unicast SA Y Y Y Basic for unicast service security/ [3] 2 Group multicast service SA N N N Considered MBS services do not need SA. 3 MBS services SA N N N Considered MBS services do not need SA. AT4 wireless S.A Page 16 of 22

17 Annex 2. AeroMACS broadcast / multicast test cases The purpose of these test procedures is to verify that an AeroMACS system has the ability to use a Multicast Traffic Connections for transmitting the same unencrypted data payload from the network to multiple MS is one single message. The test cases in this section cover AeroMACS PICS [6] item 1 in Table 116. The test cases in this section do not cover layer 3 multicast conformance testing. Therefore, layer 3 multicast procedures such as Join and Leave are assumed to work properly. Test configuration The following testing configuration is proposed to verify the Broadcast/Multicast features in AeroMACS systems. Actual use will depend upon vendor preference, capability and test tool availability in the test laboratory. Var. Attn (db) BS1 Server MS1 MS2 Var. Attn (db) BS2 ASN-GW Roles: - IGMP router Roles: - Data endpoint (broadcast message sender) General considerations Figure 1: Broadcast/multicast test configuration 1. MS1 and MS2 are the receivers of the broadcast messages. 2. Server is the sender of the broadcast messages. 3. Multicast Traffic Connection is a layer 2 capability to broadcast frames over the air from a BS to the MSs. Additionally, layer 3 multicast addressing is required for carrying the IP flows from the Server to the MSs. 4. IPv4 and IGMP have been selected to specify the test cases in this document. Other layer 3 options (e.g., IPv6 and Multicast Listener Discovery) are allowed as long as they are conformant to the AeroMACS standards. a. Either case: SServer, MS1 and MS2 shall belong to the same IP Multicast Group a. Case IPv4: c.b. IGMP is part of the routing function of the ASN-GW c. Case IPv6: MLD is part of the routing function of the ASN-GW. ASN-GW shall play the role of IGMP router AT4 wireless S.A Page 17 of 22

18 c.5. Packet IP CS rules for one Best Effort Downlink shall accommodate the Traffic flow for IP Multicast traffic between the Server and the MSs: a. Case IPv4: i. Rule 1: Protocol field: IPv4 i.ii. Rule 21: Destination Address: n, where n is the multicast group of IP devices. b. Case IPv6: i. Rule 1: Protocol field: IPv6 ii. Rule 2: Destination Address: ff02::n, where n is the multicast group of IP devices In addition to the broadcast/multicast service flows, one pair of unicast Service Flows is required between the BS and each MS to transport IP traffic like IGMP or DHCP signaling Two Base Stations are used in the test configuration in order to verify broadcast works properly across handover The variable attenuators are proposed to enforce handover. Another procedure to modify the path loss is left to test laboratory implementation Server (or another element) shall perform the role of AAA. Tests description The following table summarizes the common preamble and test process that all Broadcast/Multicast test cases have in common. Configuration Conditions Test configuration Frequency channel: Middle. TX Power Level: Medium. Compressed-IPv6-Header: Disabled. PHS: Enabled. ARQ: Disabled. HARQ: Disabled. If a HARQ MAP IE is used to specify the burst, the HARQ MAP IE used to specify the burst shall set ACK disable = 1. SS Management: Unmanaged. Security: - Primary SA for the unicast connections will use crypto suite Table 125, Item 6 from AeroMACS System Profile. - Static SA for the multicast connection will use crypto suite Table 125, Item 1 from AeroMACS System Profile. Pre-provisioned service flows: - MS1: DL Service Flow: CID1, Primary SA UL Service Flow: CID2, Primary SA AT4 wireless S.A Page 18 of 22

19 DL Service Flow: CID3, Static SA - MS2: DL Service Flow: CID4, Primary SA UL Service Flow: CID5, Primary SA DL Service Flow: CID3, Static SA AT4 wireless S.A Page 19 of 22

20 TC-MSBS-BASIC Name: Multicast/Broadcast baseline Identifier: TC-MSBS-BASIC Purpose: The AeroMACS system supports layer 3 multicast IP traffic over a layer 2 Multicast Traffic Connection. Preamble: BS1 is On. BS2 is Off. Steps: No System Action Description 1. GND1 ENTER Configure Packet IP CS rules for one Best Effort Downlink service flow between MS and BS that accommodates: - Traffic flow 1 for IP traffic between Local and Remote STA1 by selecting the following rules: Rule 1: Protocol field IPv4 Rule 2: IP multicast group ( n) 2. GND1 ENTER Configure Packet IP CS rules for one Best Effort Downlink service flow between each MS and BS that accommodates: - Traffic flow 2 for IP traffic between Local and Remote STA1 by selecting the following rules: Rule 1: Protocol field IPv4 Rule 2: IP source address (Server) Rule 3: IP destination (MS1) 3. GND1 ENTER Configure Packet IP CS rules for one Best Effort Uplink service flow between each MS and BS that accommodates: - Traffic flow 3 for IP traffic between Local and Remote STA1 by selecting the following rules: Rule 1: Protocol field IPv4 Rule 2: IP source address (MS1) Rule 3: IP destination (Server) 4. GND1 ENTER Configure Packet IP CS rules for one Best Effort Downlink service flow between MS and BS that accommodates: - Traffic flow 1 for IP traffic between Local and Remote STA2 by selecting the following rules: Rule 1: Protocol field IPv4 Rule 2: IP multicast group ( n) AT4 wireless S.A Page 20 of 22

21 5. GND1 ENTER Configure Packet IP CS rules for one Best Effort Downlink service flow between each MS and BS that accommodates: - Traffic flow 5 for IP traffic between Local and Remote STA2 by selecting the following rules: Rule 1: Protocol field IPv4 Rule 2: IP source address (Server) Rule 3: IP destination (MS2) 6. GND1 ENTER Configure Packet IP CS rules for one Best Effort Uplink service flow between each MS and BS that accommodates: - Traffic flow 6 for IP traffic between Local and Remote STA1 by selecting the following rules: Rule 1: Protocol field IPv4 Rule 2: IP source address (MS2) Rule 3: IP destination (Server) 7. GND1 ENTER Server joins IP multicast group. 8. AIRCRAFT1 ENTER Switch on MS1. 9. AIRCRAFT1 VERIFY The MS1 has successfully completed network entry and device authentication. 10. AIRCRAFT1 VERIFY Verify connectivity (1) between MS1 and Server. 11. AIRCRAFT1 VERIFY Verify the traffic between MS1 and Server is encrypted in the air interface (2). 12. AIRCRAFT1 ENTER MS1 joins IP multicast group. 13. AIRCRAFT2 ENTER Switch on MS AIRCRAFT2 VERIFY The MS2 has successfully completed network entry and device authentication. 15. AIRCRAFT2 VERIFY Verify connectivity (1) between MS2 and Server. 16. AIRCRAFT2 VERIFY Verify the traffic between MS2 and Server is encrypted in the air interface (2). 17. AIRCRAFT2 ENTER MS2 joins IP multicast group. 18. GND1 ENTER Server generates multicast traffic to IP multicast group (3). 19. AIRCRAFT1 VERIFY Verify MS1 receives multicast traffic from Server. 20. AIRCRAFT2 VERIFY Verify MS2 receives multicast traffic from Server AIRCRAFT1 AIRCRAFT2 Postamble: VERIFY Verify theat CID3 frames contain unencrypted multicast traffic is not encrypted in the air interface (2). None AT4 wireless S.A Page 21 of 22

22 Note 1: Use ping command to MS IP unicast address in Server command line interface. Note 2: Wireless analyzer is required. Note 3: Use iperf c n b 50K t 10 in Server command line interface. Selecting another tool to generate traffic is up to the test laboratory. AT4 wireless S.A Page 22 of 22

23 TC-MSBS-HO Name: Multicast/Broadcast handover Identifier: TC-MSBS-HO Purpose: The AeroMACS system supports multicast services continuity after HO procedures. Preamble: TC-MSBS-BASIC Steps: No System Action Description 1. GND1 ENTER Turn on BS2. 2. GND1 ENTER Increase path loss between MS1, MS2 and BS1. Decrease path loss between MS1, MS2 and BS2. 3. AIRCRAFT1 VERIFY MS1 performs HO from BS1 to BS2. 4. AIRCRAFT2 VERIFY MS2 performs HO from BS1 to BS2. 5. AIRCRAFT1 VERIFY Verify connectivity (1) between MS1 and Server. 6. AIRCRAFT2 VERIFY Verify connectivity (1) between MS2 and Server. 7. AIRCRAFT1 ENTER Verify MS1 continues receiving multicast traffic from Server. 8. AIRCRAFT2 ENTER Verify MS2 continues receiving multicast traffic from Server. 9. GND1 ENTER Decrease path loss between MS1, MS2 and BS1. Increase path loss between MS1, MS2 and BS AIRCRAFT1 VERIFY MS1 performs HO from BS2 to BS AIRCRAFT2 VERIFY MS2 performs HO from BS2 to BS AIRCRAFT1 VERIFY Verify connectivity (1) between MS1 and Server. 13. AIRCRAFT2 VERIFY Verify connectivity (1) between MS2 and Server. 14. AIRCRAFT1 VERIFY Verify MS1 continues receiving multicast traffic from Server. 15. AIRCRAFT2 VERIFY Verify MS2 continues receiving multicast traffic from Server. Postamble: None Note 1: Use ping command to MS IP unicast address in Server command line interface. Note 2: Use iperf c n b 50K t 10 in Server command line interface. Selecting another tool to generate traffic is up to the test laboratory. AT4 wireless S.A Page 23 of 23