AT4-ECTL TN#18 Multicast and broadcast support in AeroMACS ... s test/DRAFT... · Unicast Multicast...

___________________________________________________________________ AT4 wireless S.A. 2014 of 22 Technology Area Date: 2014-10-2323-10-2014 16:55:002014-10-082014-09-25 Code: AT4_ECTL_TN#18 Version: 1.0

EUROCONTROL AeroMACS Technical Support

Multicast and broadcast support in AeroMACS

Version: Working draft

Note Identifier: AT4_ECTL_TN#18

Author AT4 wireless (under contract with EUROCONTROL)

ALOT Technologies (under contract with EUROCONTROL)

Elaboration date: 2014-0910-dd23

Sources:

[1] RFC 2460 IETF [2] IEEE Std 802.16-2009 IEEE [3] WMF-T32-002-R010v04-Stage2 WiMAX Forum [4] RFC 3315 IETF [5] RFC 4862 IETF [6] AeroMACS PICS [7] SESAR 15.2.7 D1.1 Profile Analysis [8] SESAR 15.2.7 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. 2014 of 22 Technology Area Date: 2014-10-2323-10-2014 16:55:002014-10-232014-10-082014-09-25 Code: AT4_ECTL_TN#18 Version: 1.0

1. Current situation of multicast/broadcast in AeroMACS standards

The IEEE 802.16-2009 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 802.16-2009 6.3.22 6.3.13 7.2.2.3.2

WF System Profile Explicitly mentioned as optional in the standard or is not explicitly mentioned but has capability negotiations. It may or may not be implemented.

WF PICS The item is not required to get general “WiMAX certified” label and

Is required to get distinct “WiMAX certified with MBS capability” label.

Mandatory Not required

WF test cases available Y (PCT)

Y (MIOT)

N N

WF CRSL Not required by WiMAX certification

AeroMACS System Profile

N Y N

MOPS 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

The source of there references noted in the table above have been extracted from the standards in Annex 1.

___________________________________________________________________


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.

___________________________________________________________________


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]

Estimated peak traffic generated per cell by WXGRAPH [kbps]

Unicast Multi cast

Unicast Multi cast

20 10 3 3.33 30 9 250 75 50 25 9 2.78 25 208 100 50 15 3.33 30 250

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

(kbps) Gain (%)

Unicast Multicast Gain

(kbps)

Gain (%)

worst best worst best

20 30

9

21 1.16 0.23 250

75

175 9.72 1.92

50 25 16 1.44 0.17 208 133 7.42 1.47

100 30 21 1.16 0.23 250 175 9.72 1.92

The possible options to support multicast / broadcast according to the IEEE 802.16-2009 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

___________________________________________________________________


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

___________________________________________________________________


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 6.3.13 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”.

___________________________________________________________________


Multicast traffic connection without security

This option follows the multicast connection item as explained in the previous section based on [2] para 6.3.13, 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

___________________________________________________________________


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.

___________________________________________________________________


Figure 1: How to establish secure unicast and unsecured multicast connections in AeroMACS

MS1 BS

DL channel acquisition, MAC synchronization (DL-MAP) and obtaining UL channel parameters

Initial Ranging and PHY adjustments process (RNG-REQ/RSP)

SBC-REQ (EAP based authorization)

SBC-RSP

EAP Request

EAP Success

EAP based authorization for unicast based communications being further secured

The MS gets authenticated in the network and the security context is created

PKMv2 (SA-TEK-Challenge)

PKMv2 (SA-TEK-Request)

PKMv2 (SA-TEK-Response / SAID1 = Crypto suite T125, I6 SAID2 = Crypto suite T125, I1)

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

PKMv2 (Key-Request / SAID1)

PKMv2 (Key-Reply / SAID1)

MS acquires the valid TEK keys for SAID1

Registration

DL SF creation (Target SAID = SAID1, CID1)

UL SF creation (Target SAID = SAID1, CID2)

Establishment of secured (SAID1) unicast connections (CID1 and CID2)

DL SF creation (Target SAID = SAID2, CID3) Establishment of unsecured (SAID2) multicast connections (CID3)

MS2

Same procedure that MS1


UL SF creation (Target SAID = SAID3, CID5)


MS1 and MS2 shares unsecured CID3 multicast channel identifier

___________________________________________________________________


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,

1st 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.

2nd 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 122.1 “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.

___________________________________________________________________


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.

3rd step: Support of encrypted secure multicast connections

WiMAX Forum Profile and test cases: A profile modification is required to support 125.2 “Group multicast service SA” and 128.1 “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

___________________________________________________________________


Annex 1. Multicast/broadcast standards source WiMAX Forum System Profile

…

…

___________________________________________________________________


WiMAX Forum PICS

…

…

___________________________________________________________________


WiMAX Forum PCT TSS&TP

…

[empty section]

…

___________________________________________________________________


RTCA MOPS

…

…

___________________________________________________________________


AeroMACS System Profile:

91 1 Multicast traffic connection

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./6.3.13 [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./ 6.3.13[3]

125 1 Unicast SA Y Y Y Basic for unicast service security/ 11.9.34 [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.

___________________________________________________________________


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.

Figure 1: Broadcast/multicast test configuration

General considerations

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

MS1

BS1

ASN-GW

Server

Roles: - Data endpoint (broadcast message sender) MS2

BS2

Var. Attn (dB)

Var. Attn (dB)

Roles: - IGMP router

___________________________________________________________________


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: 224.0.0.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. 4.6. 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.

5.7. Two Base Stations are used in the test configuration in order to verify broadcast works properly across handover.

6.8. The variable attenuators are proposed to enforce handover. Another procedure to modify the path loss is left to test laboratory implementation.

7.9. 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 Test configuration

Conditions 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

___________________________________________________________________


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

___________________________________________________________________


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 (224.0.0.n)

2. GND1 ENTER Configure Packet IP CS rules for one Best Effort Downlink service flow between each MS and BS that accommodates:



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:



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:



Rule 2: IP multicast group (224.0.0.n)

___________________________________________________________________


5. GND1 ENTER Configure Packet IP CS rules for one Best Effort Downlink service flow between each MS and BS that accommodates:



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:



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 MS2.

14. AIRCRAFT2 VERIFY The MS2 has successfully completed network entry and device authentication.


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.

18.21AIRCRAFT1

AIRCRAFT2

VERIFY Verify theat CID3 frames contain unencrypted multicast traffic is not encrypted in the air interface (2).

Postamble: None

___________________________________________________________________


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 220224.0.0.n –b 50K –t 10” in Server command line interface. Selecting another tool to generate traffic is up to the test laboratory.

___________________________________________________________________


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.




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 BS2.





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 224.0.0.n –b 50K –t 10” in Server command line interface. Selecting another tool to generate traffic is up to the test laboratory.

AT4-ECTL TN#18 Multicast and broadcast support in AeroMACS ... s test/DRAFT... · Unicast Multicast...

Documents

Transcript of AT4-ECTL TN#18 Multicast and broadcast support in AeroMACS ... s test/DRAFT... · Unicast Multicast...