Keywords: Java, protocol de routage, AgentJ, NS2, simulation, tool B MyRouter Samples MyRouter(), ~MyRouter(), virtual void receivePacket MyRouterInstantiator() : TclClass("Agent/AgentJRouter/MyRouter") {} TclObject *create(int argc, const char*const* argv) {

Integrating Java Support for Routing Protocols in NS2

Résumé : Ce document présente une modification de l'outil AgentJ qui permet d'exécuter des protocols de routage en Java dans le simulateur des réseaux NS2.

Introduction

When designing a new routing protocol, an important step in its development is often to implement and experiment with it in a network simulator such as NS2 [START_REF] Fall | The network simulator -NS-2[END_REF]. While network simulators have their limits, especially in terms of the fidelity of the lower layers and -for wireless network interfaces -in the fidelity of the propagation model used for representing the behavior of physical radio waves, their use is often allowing to understand high-level and algorithmic properties of a given routing protocol. In particular in the area of Mobile Ad-Hoc Networks (MANETs), simulations are easier to perform than building a large test network of nodes, simulate mobility, and guarantee reproducibility of predefined scenarios. Using NS2 as network simulator requires the routing protocol to be implemented in C++. However, there is a tool called AgentJ which allows for running Java applications within NS2.

In particular, AgentJ enables to run unmodified and preexisting Java applications that work on top of an operating system such as Linux or Mac OS also on NS2. AgentJ rewrites all calls related to socket operations, I/O and thread handling, such that the Java application "as-is" interoperates with NS2.

AgentJ was originally developed only for application layer agents, and not for routing agents. In this document, the necessary changes to the AgentJ architecture are described that enable to use Java routing protocols within NS2, as well as detailed instructions on how to instantiate and run in NS2 a new routing protocol implemented in Java.

Availability

The modifications to AgentJ, that are described in this document, have been integrated into the core distribution of AgentJ. It is therefore available at: http://downloads.pf.itd.nrl.navy.mil/agentj/nightly_snapshots/agentj-svnsnap.tgz Remark: At the time this document has been written, only the "nightly snapshot" reflects a recent distribution of AgentJ. The "release version" is four years old.

Notation

Throughout the document, there are two different notations of "AgentJ": AgentJ and Agentj (in Courier font). The first notation (with capital "J") is used to describe the whole tool. The latter is used for some of the C++ files that are contained in the AgentJ project.

Outline

This document is composed of two parts:

Part I details how to instantiate a Java routing protocol in AgentJ. It begins with an overview of AgentJ in section 2. Section 3 contains a step-by-step instruction for integrating a Java routing protocol in NS2 using AgentJ. Section 4 presents some advanced use cases.

Part II details the modified architecture of AgentJ that allows for running routing protocols in NS2. Section 5 overviews routing in NS2. In section 6, the changes of the AgentJ codebase and architecture are detailed. Section 7 concludes the document.

Note:

• A reader, who only wants to know how to run an existing Java routing protocol implementation in NS2, should read part I.

• A reader, who is also interested in the background and the architecture of routing functionalities in AgentJ, should continue and also read part II.

INRIA

Part I

Running a Java Routing Protocol in NS2 using AgentJ

This part of the document describes how to use a Java routing protocol implementation with NS2 by using AgentJ. It details all necessary steps for integrating the implementation, plus some optional, more advanced features. The background and the architecture of routing functionalities in AgentJ are detailed in part II.

AgentJ Overview

AgentJ [START_REF] Taylor | AgentJ: Enabling Java Ns-2 simulations for large scale distributed multimedia applications[END_REF] is a tool primarily developed by Ian Taylor for the Naval Research Laboratory (NRL). The AgentJ tool serves the purpose of running Java applications as application agents on the discrete event simulator NS2 [START_REF] Fall | The network simulator -NS-2[END_REF]. NS2, without AgentJ, otherwise only supports C++ implementations. AgentJ marshals the Java commands to C++, and rewrites Java application system calls (e.g. for network packets, I/O, and time events) to use the equivalent system calls of NS2. Thread handling is rewritten completely, as NS2 is a single-threaded event-driven simulator, while Java applications often are multithreaded. For a detailed description of the rewriting mechanism of AgentJ, refer to [START_REF] Taylor | AgentJ: Java network simulations ins NS-2. An installation and user manual[END_REF]. All this means that an existing Java application does not need to be changed at all for running on NS2, adhering to the Java slogan "Write once, run anywhere". AgentJ uses the Java Native Interface (JNI) [START_REF] Liang | Java Native Interface: Programmer's Guide and Specification[END_REF] in order to connect the Java code to the C++ code of NS2. That allows NS2 to access of all Java classes, objects and methods. A callback system between the C++ (and OTcl) side of NS2 and Java is set up by AgentJ for interaction between NS2 and the Java implementation. Figure 1 depicts the basic architecture of a Java application running on a single NS2 node over AgentJ. The parts on the left side are implemented in C++ and OTcl. This includes the NS2 node and the AgentJ C++ agent that is attached to that node. For launching the Java application and sending commands to it from NS2, it needs a single entry point (similar to a main() method). Thus, a helper class has to be provided by the user, which serves as this entry point (refer to sections 3 and 6 for more details) and which is the only additional component that the user needs to implement to "glue" the Java implementation to NS2.

INRIA 3 Basic Integration

This section describes the integration of a routing protocol written in Java into NS2 using the AgentJ library as extended as described in this document. It assumes that AgentJ is properly installed, as described in the AgentJ manual [START_REF] Taylor | AgentJ: Java network simulations ins NS-2. An installation and user manual[END_REF].

Note that for C++ implementations, each new protocol implementation requires NS2 modifications, and a subsequent recompilation of NS2. However, once AgentJ has been installed, no recompilation of NS2 is necessary any more, even when a new routing protocol implementation in Java is created and added. In the following step-by-step instruction, a demonstrative example routing protocol called MyRoutingProtocol is used to show the interaction between the protocol implementation, AgentJ, and NS2.

Addition of a Helper Class as Single Point of Entry for NS2

As the single point of entry for NS2 to the routing protocol implementation, a new helper class in Java needs to be created. This helper class -as depicted on the right side of figure 2 -serves the same purpose as the main method of Java applications: to allow NS2 / AgentJ to "execute" the routing protocol implementation. In addition, the helper class provides an interface with two methods, called by NS2 for the purpose of routing. All other calls, such as for sending and receiving control packets or setting timers, are directly hooked into NS2 (by virtue of bytecode rewriting) and do not need any changes in the Java routing protocol implementation or in the helper class. The Java helper class (in the following example called MyRoutingAgent) needs to extend from agentj.AgentJAgent, and also has to implement the agentj.AgentJRouter interface. An example class definition looks as the following: public class MyRoutingAgent extends AgentJAgent implements AgentJRouter By implementing the AgentJRouter interface, the three methods getRoutingPort(), getNextHop(int), and command(String, String[]), must also be provided by MyRoutingAgent:

• public int getRoutingPort()
This method should return the UDP port number that the Java routing agent is running on. This can be any arbitrary number between 0 and 65535. NS2 will send control traffic packets to that port, and the Java routing protocol should receive control traffic from that port.

• public int getNextHop(int destination)

This method will be called from NS2 whenever a unicast data packet arrives at the node. The Java method should return the next hop for the given destination (as NS2 node ID) or -1 if no such destination has been found in the routing table. If the Java routing protocol implementation uses real IP Addresses (i.e. "java.net.InetAddress") and not only NS2 node IDs1 , this method must perform a mapping between these two address types.

An exemplary mapping (limited to node IDs smaller than 256) would be: InetAddress.getByName("0.0.0." + destination) In a future version of AgentJ, the mapping could be done within the AgentJ code.

• public boolean command(String command, String[] args)

The method command(...) evaluates the given command and its arguments. The minimal prerequisite of this function is that it allows to start the routing protocol (i.e. serves as the single point of entry). In the beforementioned example, calling the command startRouting would start the Java routing protocol. Optionally, any other command can be added in the command() method, such as for outputting the routing table as in the following example:

public boolean command(String command, String[] args) {
if (command.equals("startRouting")) { // a method needs to be added here to start the routing protocol return true; } else if (command.equals("print_rtable")) { // code needs to be added here to output routing table return true; return false; }

Installation of the Java Classes

In order to run the Java routing protocol, AgentJ has to find the corresponding class files. The location of the Java classes of the routing protocol must be added to an environmental variable called AGENTJ_CLASSPATH. In Linux, this is done by running: export AGENTJ_CLASSPATH=.:/path/to/classfiles where /path/to/classfiles needs to be replaced by the location of the Java classes. This line should be added to the $HOME/.bashrc file (if using the bourne shell) in order to execute it every time the user logs on.

Scenario Tcl Script

The scenario Tcl file that is called by NS2 must tell AgentJ which Java routing protocol to use. A complete example Tcl script can be found in appendix A. Note in particular the following lines, specific to using a routing protocol with AgentJ, that represent a minimum set of parameters that have to be defined in the Tcl script:

1. Define the routing agent:

set opt(rp) AgentJ ;# Routing Protocol ... $ns_ node-config \ -adhocRouting $opt(rp) \ ...
The routing agent is set to "AgentJ" whatever Java routing protocol is used. This avoids adding a new routing protocol in NS2.34/tcl/lib/ns-lib.tcl for every new Java routing protocol implementation. The parameter my.personal.MyRoutingAgent must be changed to the complete name of the Java class name of the helper class that has been added (as described in section 3.1).

Change Addressing Scheme

The $AGENTJ/conf/agentj.properties file has to be modified as follows:

#If you want to change to IPv4 or IPv6 addressing, #you have to add a line: #java.net.preferIPv4Stack=true #or #java.net.preferIPv6Stack=true

If the Java routing protocol uses only multicast addressing and no unicast addresses, nothing needs to be changed. In particular, in order to run the AgentJ examples in $AGENTJ/examples/udp, the file should not be modified. However, in order to use unicast addresses in the routing protocol, the line that corresponds to the preferred address family (IPv4 or IPv6) needs to be uncommented.

Note that these modifications are to the config files, read at execution time, and so do not require recompilation of AgentJ nor NS2 nor the routing protocol implementation.

Running the NS2 Simulation

The NS2 simulation can be started by launching the Tcl file ns my-sample-script.tcl

The most common error at this point is, that a java.lang.ClassNotFoundException is thrown. In that case, make sure that the location of the Java classes of the routing protocol have been correctly included in the AGENTJ_CLASSPATH environmental variable, as described in section 3.2.

INRIA 4 Advanced Features

Section 3 described the basic and necessary steps to interface a Java routing protocol in AgentJ. This section presents some more advanced features of using Java routing protocols in AgentJ.

Section 4.1 explains the steps to include more detailed tracing of control packets. Using this modification allows to output details about the payload of a control packet in NS2 trace files.

Section 4.2 details how to change the specific behavior of the routing protocol when a data packet arrives at an NS2 node. The default behavior of looking up unicast addresses for the destination of a data packet can be modified. For example, for a reactive routing protocol, a route discovery phase could be initiated.

Tracing of Routing Control Packets

Every control packet that is sent from the Java routing agent will appear in the NS2 trace file 2 , just as any control packet sent by a native C++ implementation of a routing protocol. Per default, all control traffic packets sent by the Java agent are marked as AGENTJ packets. The following NS2 trace file line represent a typical exemplary output (note that the line-breaks in the following trace entry do not occur in the NS2 trace file). Essentially, the line means that a packet has been sent (first letter 's') from RTR layer (-Nl RTR) at time 0.004 seconds after simulations start (-t 0.004). The packet originates from the node with the ID 39 (-Hs 39), is destined to port 50000 using the broadcast address (-Id -1.50000), and is of type AGENTJ (-It AGENTJ). For a detailed description of the trace file format, refer to the NS2 manual [START_REF] Fall | The ns manual (formerly ns notes and documentation)[END_REF].

Sometimes, it is desirable to display information from the payload of such a packet. This section describes how to add more detailed packet traces. Note that this advanced modification requires a recompilation of NS2.

Step 1:

If desired, the displayed name of a control packet in the trace file can be changed from the default value AGENTJ to any other name. The file NS2.34/common/packet.h has to be changed as described in the following: name_[PT_DSR]= "DSR"; name_[PT_AODV]= "AODV"; // change "AGENTJ" to the desired name name_[PT_AGENTJ] = "AGENTJ";

Step 2:

2 Refer to the NS2 manual [START_REF] Fall | The ns manual (formerly ns notes and documentation)[END_REF] for more details about tracing.

RR n°7075

For adding a detailed trace of the control traffic packet, the file NS2.34/trace/cmu-trace.cc has to be modified: Specifically, a call to a format method has to be added:

case PT_AGENTJ: format_myrouting(p, offset); break;

Next, a method format_myrouting(Packet*, int) has to be included in cmu-trace.cc that formats the output string in the trace file for the control packet. This method will be similar to the other format methods such as format_aodv or format_tora. For more information about writing a CMU trace format method, refer to the NS2 manual [START_REF] Fall | The ns manual (formerly ns notes and documentation)[END_REF].

In principle, it would also be possible to write a callback handler to the Java routing protocol implementation, which returns a string that will be output to the trace file. This is not part of the current version of AgentJ, but could be added at a later point of time.

NS2 has to be recompiled after these modifications (i.e. configure and make).

The following NS2 trace file line represent a typical exemplary output after the before-mentioned modifications: All parameters in that line that have a prefix "-P", are created by the formating function that has been defined by the user.

Changing the Behavior of the Router when Data Packets arrive

AgentJ provides a certain default behavior whenever a packet arrives at the routing layer. If it is an incoming packet from the MAC layer, AgentJ will check whether it is a control packet or a data packet. Control packets will be forwarded to the listening socket in the Java routing protocol. This socket is the INRIA one that is bound to the port number given by the method getRoutingPort() in the helper class. Data packets are delivered to the application layer of the NS2 node. Outgoing packets will be separated into unicast and broadcast traffic.

For unicast packets, AgentJ calls getNextHop() of the Java routing protocol to get a valid next hop for the given destination. Section 5 and 6.1 give more details on this. This particular behavior is implemented in the method receivePacket() of the C++ file $AGENTJ/core/src/main/c/agentj/AgentJRouter.cpp. This class can be subclassed to change the above-mentioned default behavior for incoming and outgoing packets.

The necessary steps to subclass the AgentJRouter class are presented in the following. In this example, the subclass will be called MyRouter.

Step 1:

The new files MyRouter.h and MyRouter.cpp have to be created in the directory $AGENTJ/core/src/main/c/agentj. These files should at least contain the following fields and methods (a complete example of these files can be found in appendix B): Step 2:

• MyRouter.h: #ifndef _MYROUTER #define
The new class has to be added to the Makefile.in of NS2. The rule can be added to the OBJ_AGENTJ_CPP makefile variable:

OBJ_AGENTJ_CPP = $(AGENTJ_UTILS)/LinkedList.o \ [...]
$(JAVM)/TimerWrapper.o $(JAVM)/JAVMTimer.o \ $(AGENTJ_C_SRC)/MyRouter.o NS2 has to be recompiled after these modifications (i.e. configure and make).

Step 3: In the scenario Tcl file, AgentJ has to be told to use the subclass instead of the default AgentJRouter. At the point in the Tcl file where the nodes are created and the Java agent will be attached, the following line must be changed from:

[$node_($i) set ragent_] agentj \ setRouterAgent Agent/AgentJRouter
to:

[$node_($i) set ragent_] agentj \ setRouterAgent Agent/AgentJRouter/MyRouter

Limitations of AgentJ with Routing Functionalities

At the time this document is written, AgentJ only supports routing protocols which send control traffic over UDP. TCP protocols (such as BGP) are not currently supported. In addition, it is currently not possible to run a simulation with nodes using IPv4 and IPv6 addresses at the same time. All nodes have to use the same address family.

INRIA

Part II

Routing Architecture of AgentJ

This part presents the background and architecture of routing functionalities in AgentJ. This part does not describe how to use a Java routing protocol implementation with NS2 by using AgentJ. This was described in part I.

Overview of Routing in NS2

This section presents a brief overview of the routing functionality in NS2. Figure 3 depicts the architecture of routing on an NS2 node and the flow of outgoing and incoming packets. In NS2, each mobile node has attached several layers such as the routing layer (RTR), the link layer (LL), the interface queue (IfQ), the MAC layer (MAC), and a network interface (NetIf). When a packet is ready to be sent (as illustrated in figure 3(a)), it arrives at what is called Packet Entry in the figure. From there it is handed to the RTR layer which, in turn, has to consider whether it can forward the packet. If the RTR layer finds a valid nexthop for the packet, it hands it down to the LL layer, from where the packet will progress further down the stack towards the channel. Otherwise, it drops the packet. For a more detailed insight into what happens at these layers, refer to the NS2 manual [START_REF] Fall | The ns manual (formerly ns notes and documentation)[END_REF].

Figure 3(b) depicts the process for an incoming packet from the channel. The packet is handed to the MAC layer, then to the LL layer, which hands it to the Packet Entry. The demultiplexer has to decide whether this node is the destination of the packet. If yes, then the packet has to be handed to the application agent(s). Otherwise, the packet is to be forwarded along the path to the destination and therefore is to be handed down to the RTR layer. From there, the packet will proceed as depicted in figure 3(a) and described previously. This section details what architectural changes have been made to in order to support running a Java routing protocol within NS2. On the righthand side, the Java helper class that connects the Java routing protocol with AgentJ is displayed. This helper class is a subclass of AgentJAgent and implements the Java interface AgentJRouter. Section 6.3 details the changes to the Java objects.

Overview

In the original AgentJ code, the Agentj C++ agent was attached as an application agent to the NS2 node. In contrast, in the modified version of AgentJ with routing functionalities, the Agentj C++ agent can now also be attached to an NS2 node as a routing agent (i.e. it represents the RTR layer). The AgentJRouter C++ class treats packets that arrive at the RTR layer according to the procedure illustrated in figure 5. Whenever an outgoing data or control packet arrives at the RTR layer (i.e. the Agentj object), it is forwarded to the AgentJRouter object (as illustrated in figure 5(a)). Then it has to be determined whether the packet is unicast or broadcast. If the packet is a broadcast packet, the destination is set to the IP_BROADCAST address and handed to the LL layer. If the packet is a unicast packet, the getNextHop() method on the Java routing protocol is invoked to determine the next hop address for the destination of the packet. If no next hop if found, the packet is dropped by NS2. This is reflected in the NS2 tracefile as usual (DROP). Otherwise, the destination is set to the returned next hop, and the packet is handed to the LL layer. Incoming packets are received by the Agentj object, and then handed off to the AgentJRouter object (as illustrated in figure 5(b)). If the packet is a control packet, it will be handed to a socket on the Java routing protocol. Otherwise, the packet will be treated by the demultiplexer as described in section 5.

Note that this represents the default behavior of AgentJRouter for incoming and outgoing packets, and may be overridden by the user (as described in section 4.2).

In the following subsections, the detailed description of the different new objects from figure 4 is presented.

C++ Agentj and AgentJRouter Class

In the C++ part of AgentJ, a new class called AgentJRouter has been added, and a reference is kept from the Agentj class. The reason for extracting the routing handling into a new class, rather than just adding the functionality to the Agentj class, is to separate routing tasks from agents that are only used as INRIA application agents. In addition, it allows the user to subclass the AgentJRouter in order to modify its behavior.

Modifications of the Agentj C++ Class

The Agentj C++ class is the main class of the AgentJ package, which serves as the NS2 agent that can be attached to a node. In order to add the routing functionalities, that class has been changed as described in this section and so to allow AgentJ to be used as both application agent protocol and routing protocol agent. Every C++ object in NS2 that can be accessed by Tcl, provides a method called command(). This method presents a general command interface, which allows to send any user-defined commands from NS2 to the routing agent. It receives a string array of commands and executes them. The following Tcl commands have been added in the command() function of the Agentj C++ class:

• setNativeAgentRouter This Tcl command creates a new instance of the given C++ class name which must be AgentJRouter or a subclass thereof. The command then adds a reference to the AgentJRouter object.

• setNativeRouterPort

This call will be forwarded to the AgentJRouter object to set the UDP port number it is listening to for control traffic. Incoming packets that have a destination port equal to the port number stored in AgentJRouter, will be treated as control traffic and forwarded to the Java routing protocol. Other packets are treated as data packets and forwarded to the demultiplexer of the NS2 node.

• router

All arguments of this command will be forwarded to the AgentJRouter and executed as commands on that object.

• drop-target

This sets the drop target of Agentj but also of AgentJRouter. This is necessary in order to trace dropped packets in the trace file.

• log-target

This sets the log target of Agentj but also of AgentJRouter. This is necessary in order to trace any events such as sent or received packets in the trace file.

In addition to the changes in the command() function of Agentj, a new function recv() was added. recv() represents the Packet Entry as depicted in figure 3. Any packet that arrives on the RTR layer will be delivered to the recv() method. As the Agentj object is inserted as a routing agent in NS2, but the forwarding decision is taken in the AgentJRouter object, this function just forwards the packet to the AgentJRouter object.

AgentJRouter Class

AgentJRouter is responsible for deciding how to process an incoming control or data packet as described in section 6.1. Specifically, it will acquire the next hop for data packets by calling the appropriate function on the Java routing protocol. The class has the following main methods:

• receivePacket(Packet *p,Handler *handle); Whenever the Agentj class receives an incoming packet at recv(), it will call receivePacket() on the AgentJRouter. This method will treat packets as explained in section 6.1.

• nsaddr_t getNextHop(nsaddr_t destination);

This is called from receivePacket() for getting the address of the next hop from the Java routing agent. This method will simply invoke the getNextHop(int) method on the Java side and return the result.

• virtual void forward(Packet *p, nsaddr_t nexthop);

After having received the nexthop for a data packet, the packet must be forwarded to that node.

Changes in the Java AgentJRouter and AgentJAgent

A new Java interface called AgentJRouter has been added, and the AgentJAgent Java class has been modified to accept some more Tcl commands.

AgentJRouter Interface

This interface is to be implemented by the Java routing protocol and mandates that two methods be provided:

• int getNextHop(int destination); Called from the native side whenever a (unicast) data packet arrives at the AgentJRouter class, the Java routing protocol should return a valid nexthop for the given destination, or -1 if no valid route is found.

• int getRoutingPort();

Returns the UDP port number the routing agent is running on (between 0 and 65535). AgentJRouter will decide whether a packet is a data or control packet based on the port returned by this method.

New Tcl Command in AgentJAgent

There is one new Tcl command that the AgentJAgent supports:

• setRouterAgent This command needs one argument which is the name of the C++ class that will be the AgentJRouter (e.g. Agent/AgentJRouter).

INRIA

Modifications of NS2

A new routing protocol called "AgentJ" has been added to the list of routing protocols in NS2.34/tcl/lib/ns-lib.tcl in NS2. The following code, added to ns-lib.tcl, will be called whenever a new node is created:

Simulator instproc create-agentj-agent { node } { set ragent [new Agent/Agentj] $self attach-agent $node $ragent $self at 0.0 "$ragent startup" $node set ragent_ $ragent return $ragent } A new Agentj object is instantiated and attached to the node. This agent is told to initialize itself and then attached as a routing agent of the node:

Summary

This document describes how to run Java routing protocols within the network simulator NS2. The preexisting tool AgentJ allows for using Java agents on an NS2 node, but was not capable of instantiating routing agents. A modification of AgentJ is presented in this document that enables the usage of Java routing protocols in NS2 without modification of the implemented Java routing protocol, adhering to the Java slogan "write once, run everywhere". In addition, once AgentJ has been installed, NS2 does not need to be recompiled when a new Java routing protocol implementation is added. All parameters that need to be changed can be set in configuration files or in environmental variables, read at execution time. AgentJ with the proposed routing extension, keeps full compatibility with NS2, meaning that it allows for output of all events in the usual NS2 trace files. Consequently, all evaluation tools used for parsing NS2 trace files can be used without modification.

A Sample Tcl File

Figure 1 :

 1 Figure 1: Architecture of an AgentJ agent attached to an NS2 node

Figure 2 :

 2 Figure 2: The helper class on the right side serves as single point of entry from NS2 to the Java routing protocol implementation.

2 .

 2 Attach the Java agent to a node set node [ $ns_ node ] ;# create a new node # The following line must be changed to reflect # the name of the Java class. [$node set ragent_] attach-agentj my.personal.MyRoutingAgent # The following lines needs only be changed for advanced settings # (refer to section 4). [$node set ragent_] agentj setRouterAgent Agent/AgentJRouter $ns_ at 0.0 "[$node set ragent_] agentj startRouting"

  s -t 0.004000000 -Hs 39 -Hd -2 -Ni 39 -Nx 1216.36 -Ny 594.63 -Nz 0.00 -Ne -1.0 -Nl RTR -Nw ----Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 39.9999 -Id -1.50000 -It AGENTJ -Il 25 -If 0 -Ii 0 -Iv 254

  void CMUTrace::format(Packet* p, const char *why) { hdr_cmn *ch = HDR_CMN(p); int offset = 0; ... switch(ch->ptype()) { case PT_AODV: format_aodv(p, offset); break; case PT_TORA: format_tora(p, offset); break;

  s -t 0.004000000 -Hs 39 -Hd -2 -Ni 39 -Nx 1216.36 -Ny 594.63 -Nz 0.00 -Ne -1.0 -Nl RTR -Nw ----Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 39.9999 -Id -1.50000 -It AGENTJ -Il 25 -If 0 -Ii 0 -Iv 254 -P olsrv2 -Pn 1 -Ps 7996 [-Pt HELLO -Po 1 -Ph 1 -Pms 41054]

Figure 3 :

 3 Figure 3: Layer architecture of a mobile node in NS2 for outgoing and incoming packets

Figure 4

 4 Figure 4 depicts the general architecture of the modified version of AgentJ. On the lefthand side, the NS2 and AgentJ internal objects (Agentj and AgentJRouter) are depicted. These are implemented in C++ and use some OTcl code. Section 6.2 details the changes to the C++ objects.On the righthand side, the Java helper class that connects the Java routing protocol with AgentJ is displayed. This helper class is a subclass of AgentJAgent and implements the Java interface AgentJRouter. Section 6.3 details the changes to the Java objects.In the original AgentJ code, the Agentj C++ agent was attached as an application agent to the NS2 node. In contrast, in the modified version of AgentJ with routing functionalities, the Agentj C++ agent can now also be attached to an NS2 node as a routing agent (i.e. it represents the RTR layer). The AgentJRouter C++ class treats packets that arrive at the RTR layer according to the procedure illustrated in figure5.

Figure 4 :

 4 Figure 4: Modified architecture with an AgentJRouter interface

Figure 5 :

 5 Figure 5: Decisions to take on the RTR layer

RR n°7075

In NS2, every node has a unique identifier, the NS2 node ID. Per default, this ID is an unsigned integer (including 0).INRIA

Acknowledgments

Ian Taylor was very helpful when developing the routing extension to AgentJ. He spent a lot of time and effort on AgentJ, a tool which the author uses intensively for his current research.

INRIA

The routing functionalities have been included in the current distribution of AgentJ that is available for download at: http://downloads.pf.itd.nrl.navy.mil/agentj/nightly_snapshots/agentj-svnsnap.tgz $node_(4) set X_ 969.778307544 $node_(4) set Y_ 310.299546663 $node_(4) set Z_ 0.000000000 # Node Movements $ns_ at 0.0 "$node_(0) setdest 243.402233718 887.494440154 3.371378059" $ns_ at 29.6 "$node_(0) setdest 202.222490121 796.366899217 3.442128171" $ns_ at 0.0 "$node_(1) setdest 261.037139025 180.754134361 4.413709080" $ns_ at 23.4 "$node_(1) setdest 248.041392110 279.906091286 4.413709080" $ns_ at 0.0 "$node_(2) setdest 251.526166181 466.628882483 7.977160606" $ns_ at 13.7 "$node_(2) setdest 151.528816489 467.356930946 7.977160606" $ns_ at 0.0 "$node_(3) setdest 525.639788716 538.657734976 7.366205977" $ns_ at 13.5 "$node_(3) setdest 427.546365593 558.091734566 4.646736198" $ns_ at 0.0 "$node_(4) setdest 999.999900000 311.899405137 2.131682882" $ns_ at 14.1 "$node_(4) setdest 930.361317453 315.585892139 2.131682882" puts "Starting Simulation..." flush stdout $ns_ run


Crater O Forni

Forni

P Beck

J R Johnson

E Dehouck

C Quentin-Nataf

O Beyssac

A Udry

A Cousin

R B Anderson

L Mandon

C Royer

E Clavé

F Poulet

S Le Mouélic

P.- Y Meslin

P Pilleri

V Debaille

S Maurice

R C Wiens

S M Clegg

T Fouchet

A J Brown

COMBINING SUPERCAM LIBS AND VISIR: CONSTRAINING THE MINERALOGY IN JEZERO

Introduction:

Since the landing at Jezero in February 2021, the NASA Perseverance rover has visited the crater floor units, which are the structurally deepest and consist of stratified rocks [1]. Onboard Perseverance, SuperCam is a versatile remote-sensing instrument providing chemical and mineralogical information from the same spot on a target at a sub-mm to mm scale by combining Laser Induced Breakdown Spectroscopy (LIBS), time-resolved Raman and visible and infrared spectroscopy (VISIR), a microphone and a remote micro-imager (RMI) [2], [3]. In this abstract, we present results combining LIBS and VISIR techniques. SuperCam Laser-induced breakdown spectroscopy (LIBS) obtains emission spectra of materials ablated from the samples in electronically excited states. SuperCam passive reflectance spectra cover the 0.39-0.85 μm (VIS) and 1.3-2.6 μm (NIR) ranges, which allow the identification of a wide variety of minerals, especially hydrated species [4], and hence can help to constrain past environmental conditions at Jezero crater We found that all of the floor units are igneous, with lava flows apparently comprising the upper units as part of the Máaz formation, while the lower formation [5], Séítah, is an olivine cumulate, produced by gravitational settling of olivine crystals in a large melt body [6,7]. After exploring the floor, Perseverance drove to the edge of the delta formation and began a reconnaissance traverse style of observations starting at Enchanted Lake, just below an arm of the delta formation, and then moving into Hawksbill Gap, climbing between Devil's Tanyard and Hogwallow flats. This approach, combining the chemical information from the LIBS data and the mineralogical information from the VISIR can provide additional constraints on the formation of the detected phases and/or the alteration processes in Jezero rocks.

Data and methodology: To achieve our analysis objectives we used a dimensionality reduction of the initial data. For LIBS we use the Major Oxide Composition (MOC) data derived from multivariate regression methods [8]. For VISIR, we use some diagnostic spectral parameters computed using the formalism described in [9] that generally are similar to those compiled by [9] for CRISM and by [10] for ChemCam on board the Curiosity Rover, as well as some custom parameters adapted to the SuperCam data.

We selected all the LIBS spectra jointly acquired with VISIR data and removed all suspect data based either on the quality of the LIBS signal or the quality of the VISIR data. The magnitude of a specific spectral parameter is plotted into a classical ternary diagram in which pure minerals can be localized, such as the Wo-En-Fs diagram for pyroxenes. Additionally, a diagram can be displayed for each type of unit that has been identified.

Results: We analyzed several parameters with this approach, as discussed below.

1.3 -1.8 μm slope: This slope is indicative of the presence of olivine [9,11]. Olivine has mainly been identified with SuperCam data in the Seítah unit [6,11]. On a Si-Fe-Mg diagram, the highest slopes (between 0.4 and 0.7 radiance/μm) cluster in two regions, one corresponding to the olivine but another that corresponds to the presence of orthopyroxenes which have a different molar (Fe + Mg) / Si ratio (Fig. 1.). Note that some points with low Si have also high slopes and may trace the presence of Mg-Fe carbonates [12]. dominated by the presence of olivine and the spectra are apparently insensitive to the presence of pyroxenes. However, selecting the highest slope spectra in both clusters and ratioing their mean suggests the presence of orthopyroxenes in the spectra corresponding to the LIBS orthopyroxenes spectra (Fig. 2.). Not only are the strong values of this slope interesting, but the lowest values are diagnostic of some particular phases like the coatings that cluster at a Wo20-En25-Fs55 composition in the pyroxenes diagram, or the sulphates that generally have low Si content, relatively high Mg content, and high H content based on the H line area at 655 nm [13].

Figure 2: Ratio of the mean spectra in the two cluster exhibiting the good match with RELAB experimental orthopyroxenes spectra (dashed lines). The bump in the 1.9-2.0 µm corresponds to variation of the water band at 1.9 µm and atmospheric residuals.

Absorption band at 2.28-2.32 μm: This spectral parameter traces the Fe/Mg-OH vibration and is diagnostic of Fe/Mg-phyllosilicates like Fe-smectite (e.g. nontronite) Mg-smectite (e.g., saponite), serpentine, talc-bearing material, chlorite, and prehnite. The absorption band moves from the lower to higher wavelengths with increasing Mg content. It is generally associated with structural and OH absorption features at 1.4 μm and a 1.9 μm feature. It sometimes traces the alteration of olivine and pyroxene. Strong absorption at 2.32 μm (Mg-OH) are found in the Seítah formation and are correlated with olivine. This would mean that the olivine is altered, but this observation is in contradiction with the images, which exhibit apparently fresh crystals, and that the H signal is relatively low. The alteration might be related to secondary phases at the grain boundaries [8]. The strongest absorptions are found in the Amalik outcrop in the Delta unit. They are found in mainly three targets: Chiniak (Sol 565), Novarupta (Sol 572) and Hook_Glacier (Sol 424). These infrared signatures coupled to chemistry might indicate the presence serpentines. From the stoichiometry they can represent alteration of olivine and orthopyroxene. It is worth to note that all those targets are very much enriched in Cr at the percent level. The presence of Cr can be primary at least for the olivine or can come from the substitution of Al or Fe in phyllosilicates in the octahedral sites (Hisingerite, Bedeilite) [14]. Their chemical composition is very similar to the Seítah unit composition and may reflect high temperature deep hydro-thermalism [START_REF] Dehouck | this meeting 1244.pdf 54th Lunar and Planetary Science Conference 2023[END_REF] Discussion and future work: The combined analysis of chemical data from the LIBS and mineralogical data from the VISIR provides good agreement between the two sets of data. However, some discrepancies were noticed. At least three causes can explain these differences. The first is related to the differing footprint sizes of the two techniques (LIBS spot size is of the order of 300 μm while the VISIR footprint size is much larger of the order of 0.11 mrad i.e. 3.3 mm at 3m). The second is related to the small spatial offset between the centers of the two observations. This means that, while the LIBS technique can sample very tiny grains, the VISIR integrates signals from a much broader area and the mixing of phases is more likely. The third cause is related to the mineralogical response to the VISIR signal: Strong absorptions mainly due to the Fe 2+ /Fe 3+ can easily dominate the spectra and mask the presence of other phases even if the latter dominates the mixture. We have analyzed other spectral parameters like the absorptions at 1.4 μm and 1.9 μm as well as a sulphate index [9]. Other spectral indices will be investigated in the VIS and joint LIBS/VISIR multivariate reduction techniques will be used to better constrain endmembers.

Figure 1 :

 1 Figure 1: Si-Fe-Mg ternary diagram representing the magnitude of the 1.3 -1.8 μm slope that concentrates in two clusters, one close to orthopyroxenes (Si50-Fe25-Mg25) and one close to olivine (Si40-Fe25-Mg35).This ratio equals two for olivine and equals to one for orthopyroxene. Consequently, the slopes are

Acknowledgments: This research utilizes spectra acquired by Jack Mustard with the NASA RELAB facility at Brown University This work has benefited from support from INSU-CNES. The NASA Mars Exploration Program is thanked for supporting this work in the US.


Sharmin Sultana

Zhiping Ye

Savita K P Veerapandian

Axel Löfberg

Nathalie De Geyter

Rino Morent

Jean-Marc Giraudon

Jean-François Lamonier

Synthesis and catalytic performances of K-OMS-2, Fe/K-OMS-2 and Fe-K-OMS-2 in post plasma-catalysis for dilute TCE abatement

Introduction

A large and important group of air pollutants consists of Volatile Organic Compounds (VOCs) which particularly harm human health and our environment. Along with carcinogenic and mutagenic effects on human health [1], VOCs are also precursors to ground level ozone which is principally responsible for photochemical smog. The research of innovative technologies for VOC abatement is stimulated to accommodate the new stringent standards in terms of VOC emission. One emerging strategy is the coupling of 2 existing complementary technologies, namely here Non Thermal Plasma (NTP) and Catalytic Total Oxidation (CTO), to get a more efficient process for VOC removal in air. Indeed although NTP displays a high reactivity in air towards VOC removal at atmospheric pressure and ambient temperature, it has however a low CO2 selectivity currently producing other VOC by-products, CO, and hazardous ozone. This lack of CO2 selectivity can be overcome by the addition of a O 3 decomposition/VOC total oxidation catalyst downstream of the plasma discharge to form a post plasma-catalysis (PPC) system [2][3][4]. Here the catalyst takes advantage of its high efficiency towards the destruction of ozone to give active species able to oxidize the plasma processed hazardous byproducts and the possibly remaining VOC into CO2.

The performances of NTP in PPC have already been investigated in particular for trichloroethylene (TCE) removal which is a very reactive molecule towards cold plasma in dry/wet air [5][6][7]. Indeed TCE is recognized as a highly toxic chlorinated VOC widely used in industry as metal degreasing agent. The design of the catalyst has to be performed taking into account some basic requirements such as ozone decomposition ability, VOC total oxidation capacity, as well as hydrothermal stability and resistance to chlorine. Among the different catalysts already investigated MnO 2 appears to be very interesting, especially, due to its very high activity towards O3 degradation [8]. However MnO2 shows various crystallographic phases. Cryptomelane, an octahedral molecular sieve (OMS) is one allotropic form of MnO 2 having a (2 × 2) tunnel structure (OMS-2). The structure is made of the superposition of 4 units of 2 edged MnO 6 octahedra building blocks connected by corners along the c axis forming 1D microporous square tunnel of 0.46 nm in size. K + cations which are located inside the (2 × 2) tunnels provide charge balance and stabilize the structure (K-OMS-2; general formula K x Mn8 O 16 with an average manganese oxidation of about 3.8). The open structure of the channels, the easy cycling of Mn4+ /Mn 3+ and the high mobility of lattice oxygen as well as more recently the morphology of the particles have been put forward as important characteristics to take into account for their activity in CTO of VOCs [9][10][11][12][13][14][15][16][17][18]. On purpose MnO2 oxides have been already shown interesting TCE abatement properties in PPC [6,7,19,20]. The TCE total oxidation performed in moist air in the presence of CO 2 was previously investigated as a function of energy density using an atmospheric pressure negative DC luminescent glow discharge combined with a cryptomelane catalyst positioned downstream from the plasma reactor [19,20]. The ability of the catalyst to decompose plasma generated ozone allows getting active oxygen species enabling the destruction of plasma generated polychlorinated hazards and the enhancement of TCE abatement. The main limitation is the side formation of some C1 chlorinated compounds believed to be in line with a partial chlorination of the catalyst when the temperature of the catalyst is to low [19,20]. In order to promote the efficiency of the PPC process towards VOC abatement a possible strategy is to improve the physical and catalytic properties of K-OMS-2 material by doping. Indeed doping of single-type, low or high-valent metal transition cations, has been previously showed to produce cryptomelane with novel morphologies [21] and improved catalytic properties [22]. Doping cryptomelane with various cations of different types can improve the textural properties [23,24], modify Mn average oxidation state (AOS) [9,25,26] and thermal stability [9,23,26,27], increase structural defects, e.g., vacancies [23,27], and also enhance the reactivity of cryptomelane towards the catalytic oxidation of various organic pollutants [24,[28][29][30]. It follows from these considerations that the physico-chemical properties of the metal doped K-OMS-2 depend on the nature of the doping metal and of the synthesis conditions, such as among others, through the mode of incorporation and temperature of calcination of the oxide precursor material. As a result the doping cation can be incorporated into the channels, partially replacing K+ ions and/or substitute M 3+ or Mn 4+ cations in MnO 6 octahedra and/or be present as dispersed transition metal oxides supported on the cryptomelane phase [23]. Among the possible transition metal dopants Fe has been chosen as it has been previously reported that Mn-Fe oxides may be promising catalysts for ozone decomposition [31]. Taking advantage of this property, Mn-Fe oxides dispersed on cordierite have been recently used successfully in a PPC process for the decomposition of diethylether [32]. Additionally Fe doped cryptomelane catalysts have been reported to enhance VOC total oxidation [33]. Reported Fe-doped cryptomelane synthesis methods include hydrothermal treatment of Fe-doped layered birnessite [9], redox precipitation under reflux [34], sol-gel assisted combustion methods [26], addition of iron precursor to cryptomelane and heating [33].This present study focuses on the preparation, characterization and evaluation in TCE oxidation (in presence of moist air) of Fe-doped K-OMS-2 oxides placed downstream from a NTP reactor prepared by introduction of Fe either by co-precipitation [34] or by deposition of Fe(OH) x (x = 2-3) over the K-OMS-2 solid [35] prepared by the reflux method in order to modify the chemical/physical properties of the catalysts.

Materials and methods

Catalyst preparation

The introduction of iron to cryptomelane was performed by 2 different ways inspired by literature: (i) by co-precipitation followed by calcination at 450 °C (Fe-K-OMS-2) [34]; (ii) by deposition of Fe(OH) x(x = 2; 3) over K-OMS-2 followed by calcination at 450 °C (Fe/K-OMS-2) [35]. A reference cryptomelane (K-OMS-2) was also synthesized.

Synthesis of K-OMS-2

A KMnO 4 (Fluka, 99%; 6.385 g in 150 mL; n Mn(II) ≈ 1.5 n Mn(VII) ) solution was added dropwise to manganese (II) acetate (Mn(CH 3CO 2) 2 • 4H 2O; Prolabo, 99%; 14.854 g in 50 mL) dissolved in a CH 3COOH/CH3COOK buffer solution of pH 4.5 while stirring. A black brown precipitate was rapidly formed and the mixture was stirred 24 h at reflux. The precipitate was then washed thoroughly with distilled water and dried overnight at 100 °C. The resulting powder was calcinated at 450 °C for 4 h (1 °C/min) in air (0.3 L/min).

Synthesis of Fe-K-OMS-2

A KMnO 4 (Fluka, 99%; 6.98 g ≈ 0.044 mol in 80 mL) heated at 60 °C was added to an aqueous acidified solution (CH 3COOH; Alfa Aesar, 99%; 12 mL of a 2 mol/L solution into 90 mL of water) of Mn and Fe nitrate precursors ((Mn(NO 3 ) 2•4H 2O; Sigma-Aldrich, 97%; 11.76 g ≈ 0.045 mol) and Fe(Fe(NO 3 )3 •9H 2O; Fisher Scientific, 98%; 1.9 g ≈ 0.00461 mol)) to get a precipitate. The suspension was stirred vigorously at reflux for 20 min. An additional amount (≈8 mL) of 2 mol/L acetic acid was added to retrieve the volatilized acetic acid during reaction. The precipitate was separated through centrifugation and washed with deionized water several times until neutral pH, followed by drying at 100 °C for 12 h. The resulting solid was calcined in air (0.3 L/min) at 450 °C for 4 h (1 °C/min).

Synthesis of Fe/K-OMS-2

0.41 g of Fe(NO 3 ) 3•9H 2O (Fisher Scientific, 98%; ≈0.001 mol) and 0.40 g of (NH 4) 2Fe(SO 4) 2 •6H 2O (Sigma-Aldrich, 98%; ≈0.001 mol) (n Fe(II) = n Fe(III)) were dissolved in 50 mL of water (pH = 2.6). A KOH (Sigma-Aldrich-85%) solution of 1 mol/L was added dropwise to the initial solution, under constant stirring, to a final pH of 9.6 allowing the successive precipitation of Fe(OH)x (x = 2,3). At that stage K-OMS-2 (n Fe/n Mn = 0.10) was introduced above this pH as powder to the aqueous suspension and KOH was again added dropwise until a pH of 12. The resulting solid was intensively washed with distilled water and dried before to be calcined at 450 °C for 2 h.

Catalyst characterization

K, Mn and Fe elemental analyses were performed by inductively coupled plasma-optic emission spectroscopy (ICP-OES) at the REALCAT platform (Lille University). The sample preparation was made by dissolving 10 mg of dried and ground solid in 1.5 mL of concentrated aqua regia solution. Solutions were heat at 50 °C and stirred during 12 h. All sample solutions were stirred and the volume was adjusted up to 50 mL with ultrapure water before being analyzed by ICP-OES. X-ray diffractograms were recorded using a Bruker AXS D8 Advance diffractometer. Data were collected using the Cu Kα line in the 10-70° 2-theta range with a 0.02° 2 θ step and a counting time of 3 s per step. Crystallite size was estimated from the FWHM of the peak located at 2 θ= 28.9° using the Scherrer equation, after correction of the FWHM to account for the instrumental broadening using the Diffrac. EVA-crystallite size determination.

The Raman spectra of the samples were recorded at room temperature using a Raman microprobe (Labram HR) equipped with a Peltier-cooled detector. The exciting light source was the 488 nm line ofan Ar + -ion laser and the spectral resolution was ± 1.5 cm-1.

The morphology of the materials was observed using Scanning Electron Microscopy images recorded on a Hitachi S-4700 apparatus.

The specific surface areas were determined using a conventional multipoints BET nitrogen adsorption method with a MicromeriticsTristar II apparatus. Prior to nitrogen adsorption, the samples were outgassed for 4 h at 150 °C under vacuum.

TGA analyses were performed on sample size of about 10 mg in air flow (50 mL/min) with a heating rate of 10 °C/min up to 800 °C using a TA Instruments TGA-SDT 2960.

Temperature programmed reduction (TPR) were carried out using a Micromeritics 2920 Autochem II Chemisorption Analyzer. 50 mg sample was put into a quartz U-shaped tubular quartz reactor. The samples were pre-treated in flowing Ar at 150 °C for 60 min followed by cooling down to room temperature. The reducing gas was a mixture of 5 vol.% H2 /Ar at a total flow rate of 50 mL/min. The temperature was allowed to increase from 25 °C to 800 °C with a heating rate of 10 °C/min.

Experimental set-up and experimental procedure

Fig. 1 shows the schematic diagram of the experimental set-up including a trichloroethylene generator, a plasma-catalysis reactor and an exhaust gas analysis section. Trichloroethylene (99.99% purity, A-CROS) was evaporated by bubbling with moist air (RH = 15%) and diluted with air before to be introduced into the plasma reactor. The flow rate and TCE concentration were adjusted by mass flow controllers (MFC) and fixed at 30 L/h and 300-350 ppmv, respectively. The 10-pin-to plate plasma reactor was similar to the one used before [36] except that the pin to plate modules were herein doubled. A negative DC corona/glow was used as discharge. A quartz tube filled with 0.5 g of catalyst diluted in 3 g of SiC (EMB 45053-Prolabo; 0.105 mm) pretreated with dry air at 350 °C for 4 h (12 L/h) was located downstream from the plasma reactor. The performances of the hybrid process toward TCE removal was assessed regarding the following sequence: the catalyst was first exposed to the reactive gas flow at 50 °C for 10 min. Then the plasma was turned on and after plasma stabilization of 5 min the energy density was allowed to increase by step of 30 J/L of 5 min duration from 30 J/L to 120 J/L. This sequence was repeated for catalyst temperatures of 100 and 150 °C (3 °C/min). The TCE abatement efficiency, COx and CO2 yields as well as the identification of by-products were determined using a FT-IR spectrometer (Bruker, Vertex 70) [37]. Ozone formation was analyzed by an UV ozone monitor (Envitec, model 450). To evaluate the efficiency of the process the following parameters were estimated:

The TCE abatement was calculated from : where [TCE] in and [TCE] out were the concentration introduced in the reactor and that measured at the exit of the catalytic reactor, respectively. The CO yield, Y CO, and the CO2 yields, Y CO2, were calculated as follows:

. Chemical analysis

The physico-chemical characterizations of the fresh materials are given in Table 1. A formula of K0.12 MnO2 was obtained for K-OMS-2sample based on the ICP-OES analysis. Charge balance calculation gives a Mn AOS of 3.88 which agrees with those of 3.87 [25] and of 3.89 [38,39] reported elsewhere for cryptomelane synthesized hydrothermally [25] or by reflux method [38,39], respectively. It is worth mentioning that in cryptomelane-type solid, Mn AOS usually varies between 3.6 and 3.8 in line with the mixed-valence Mn(IV) and Mn(III) structure [40]. Based on elemental analysis, the Fe/K-OMS-2 and Fe-K-OMS-2 samples exhibit Fe/Mn atomic ratios of 0.10 and 0.077, respectively, in perfect agreement with that present in the reaction mixture of 0.10 for the impregnated sample but at a slightly higher value for the co-impregnated sample (Fe/Mn ratio of 0.52 in solution). As expected Fe/K-OMS-2 oxide displays a comparable K/Mn ratio than that of K-OMS-2 in agreement with dispersion of iron based oxides over K-OMS-2 acting as the support. Conversely the K/Mn ratio of 0.027 is far less than that expected and shows that the mode of introduction of the dopant plays a key role in the nature of the final oxide.

Structural properties

The X-Ray diffraction patterns of K-OMS-2 and Fe/K-OMS-2 catalysts (Fig. 2) showed peaks which can be indexed to the tetragonal K-OMS-2 phase (JCPDS: 44-0141) (space group (I 4/m) with unit cellparameters a = b = 9.81 Å and c = 2.85 Å [41]. Furthermore the mean crystallite size keeps rather constant, of about 14-15 nm (Table 2), for both solids. Additional peaks located at 36.1° and 63.0°can be attributed to Fe-Mn spinels such as Fe (Fe 1.08Mn 0.92 )O 4 (JCPDS 01-077-9278) or/and FeMn 2O 4 (JCPDS 04-006-9026), rather than maghemite (γ-Fe 2O 3 ) phase (JCPDS 13-0458), dispersed on cryptome-lane without discarding the possibility of segregated amorphous or/and low content Fe and/or Mn (hydroxy)oxide phases. Otherwise the XRD pattern of Fe-K-OMS-2 shows very broad envelopes of overlapping peaks of low intensity whose positions match those of K-OMS-2 to be Table 1 Chemical composition of the fresh catalysts. consistent with the presence of a very disordered cryptomelane phase. The lattice vibrational behavior of both the undoped and Fe based K-OMS-2 materials was studied by Raman spectroscopy in order toprobe the effect of iron addition on the spectral features of the K-OMS-2 material (Fe/K-OMS-2), to validate the postulated formation of cryptomelane and check for the presence of segregated crystalline and/or amorphous metal oxides. OMS-2 type materials crystallize into a body centered tetragonal structure with a space group I4/m. Group theory predicts 15 Raman-active modes 6A g + 6B g + 3E g [42]. The Raman spectrum of K-OMS-2 displayed in Fig. 3 reveals only 9 characteristic peaks at 185, 280, 330, 386, 470, 512, 575, 630, and 745 cm-1 for the regular K-OMS-2 in good agreement with the data reported by Gao et al. [42]. The 2 most intense peaks at 574 and 634 cm-1 which have been previously associated to Mn-O vibrations along and orthogonal to the direction of the MnO6 octahedral double chains (A g modes), respectively have been previously recognized to be the diagnostic of a well-developed tetragonal structure with 2 × 2 tunnels [42]. The Raman spectrum of Fe/K-OMS-2 shows these 2 characteristic lines but much enlarged than those of the K-OMS-2 oxide. Conversely the Raman contributions in the 200-400 cm-1 spectral region have almost disappeared and an apparent additional line is now observed at 556 cm-1 which can be due to the presence of segregated phases or/and different local environment of manganese.

Textural properties

The textural properties are significantly improved when adding Fe. In particular the BET specific surface increased 4 times and the pore volume 2 times for Fe-K-OMS-2 in comparison with K-OMS-2 (Table 2). The representative SEM image of K-OMS-2 solid which is similar to that of Fe/K-OMS-2 solids is displayed in Fig. 4a. The needle-like morphology is clearly observed (average length: 1 μm). Conversely the SEM image of the Fe-K-OMS-2 solid exhibits particles of pseudo-spherical morphology (average size: 300 nm) as shown in Fig. 4b. It turns out in that case that the elongation growth of the particles is partially inhibited. This observation may suggest some Fe incorporation into the Mn framework of cryptomelane as previously reported in the literature [34]. However the assignment of the exact position of Fe in the structure is a difficult task. Complementary experiments have to be implemented to assess the effect of the Fe addition on the location of Fe in the structure through isomorphic substitution of Mn n+ in the octahedral sites of Mn n+ or partial replacement of K+ into the tunnels of the structure.

Temperature programmed reduction (H 2-TPR)

Fig. 5 shows the TPR profiles of the materials. It is worthy to mention that the H2 consumption profile of K-OMS-2 shows a global envelope rather similar to those reported by T. Chen et al. and W. Y. Hernándeza et al. [43,44]. Four peaks at 300, 338, 356 and 374 °C can be seen. The lowest temperature reduction process has been previously attributed to the consumption of structural oxygen close to the surface leading to oxygen vacancies [44]. The three other ones are in line with a consecutive reduction scheme involving the successive steps:

MnO 2 -> Mn 2O 3 -> Mn3 O 4 -> MnO [45].
The peaks observed at 289, 325, 334, 338, and 365 °C in the Fe/K-OMS-2 solid were shifted to lower temperature in comparison to the K-OMS-2 oxide. The TPR profile appears more complex due to the additional reducibility of the Fe-Mn spinel dispersed on K-OMS-2, among others. By opposition the Fe-K-OMS-2 solid shows 3 contributions at 210, 277, and 301 °C in the low temperature range which are well separated from the peak at higher temperature (407 °C). It is worth mentioning that the temperature of the onset of reduction decreases as follow: K-OMS-2 > Fe/K-OMS-2 > Fe-K-OMS-2. The improved oxygen lability observed for Fe-K-OMS-2 may be related to many defects such as oxygen vacancies which would promote the degradation of the VOC and reaction intermediates. Table 2 lists the H 2 consumption of the different catalysts in the reduction process. The H2 consumptions of K-OMS-2, Fe/K-OMS-2 and Fe-KOMS2 are 9.90, 9.29, and 8.75 mmol/g, respectively. Based on the H2 consumption and the corresponding Mn content given in Table 1, the Mn AOS for K-OMS-2 by assuming MnO as final product [45] is calculated to be 3.82 in good agreement with the value of 3.88 obtained by ICP-OES. The Mn AOS of Fe/K-OMS-2 and Fe-KOMS2 are calculated to be 3.68 and 3.61, respectively, by assuming all iron in the Table 2 Textural, structural and reducibility properties of the fresh catalysts Fig. 3. Raman spectra of the synthesized materials (A: K-OMS-2; B: Fe/K-OMS-2; C: Fe-K-OMS-2). samples to be Fe 3+ and by assuming Fe 3O 4 as the end product of reduction. As a result the Mn AOS decreases with the introduction of Fe. When considering Fe/K-OMS-2 the Mn AOS decrease is mostly due to the reduction of segregated Fe-Mn spinel species in accordance with XRD results. In a similar way segregated amorphous or well dispersed related Fe-Mn may also contribute to the Mn AOS decrease for Fe-K-OMS-2 sample.

Thermal stability

Thermal gravimetric analysis (TGA) and differential thermal analysis (DTA) profiles for the different solids performed in dry air are displayed in Fig. 6a-b and relevant results are in Table 2. The differential thermogravimetric (DTG) curves of K-OMS-2 and Fe/K-OMS-2 samples have similar behavior showing three separate steps in the temperature range of 25 °C-800 °C. The two first steps at temperature up to 200 °C correspond to the elimination of physisorbed and chemisorbed water in different environments [46]. When the temperature exceeds 200 °C, the weight loss slows down until the temperature of about 500 °C. With the temperature increase up to 780 °C, the third weight loss which increases to 3.6 and 2.4% for K-OMS-2 and Fe/K-OMS-2, respectively, have been ascribed to the desorption of water inside the (2 × 2) channels as well as the departure of some structural oxygen close to the surface inducing oxygen vacancies without destroying the materials [47]. The removal of these species agree with the observance of an endothermic peak located at 642 and 673 o C for the free and iron containing oxide, respectively. In comparison with the two previous solids the DTA trace of Fe-KOMS-2 shows two weight loss steps in the range 25-200 °C and 400-550 °C to stabilize beyond 550 °C. As previously observed the first weight loss corresponds to the removal of water while the second weight loss is related to the crystallization of the solid consistently with DTA behavior. The performance of the NTP alone toward TCE abatement has been investigated as a function of energy density which is defined as the energy given by the plasma to 1 L of gaseous gas. The TCE conversion increases with ED due to the formation of more energetic electrons as shown in Fig. 7. The production of plasma generated ozone increases linearly with time to reach 150 ppmv at 120 J/L. The COx yield is low, about 15% (not shown), demonstrating the poor mineralization of TCE into CO 2. This is in line with the formation of polychlorinated by-products such as phosgene (PG), dichloroacetylchloride (DCAC) and trichloroacetaldehyde (TCAD) identified from FT-IR spectra as previously reported [37].

Post plasma-catalysis

Figs. 8 and 9show the evolution of TCE abatement and CO 2 yield as a function of energy density (ED) for the 3 catalysts working in post-plasma configuration compared to those of NTP alone. First of all with plasma turn off, at a catalyst temperature (Tc) of 50 °C, it is observed 62% TCE abatement over Fe-K-OMS-2 oxide in comparison with the 2 other catalysts for which the TCE abatement is close to zero. This is explained by the high surface area of the catalyst enabling to retain a high amount of TCE in agreement with a CO2 yield close to zero. When the surface of the catalyst would be saturated with the VOC a decrease in TCE conversion would be expected to occur. With plasma turn on, the TCE conversion was less than that of NTP at ED of 30 J/L suggesting that the downstream catalyst was working in unsteady-state conditions. At higher ED the TCE conversion profiles as a function of ED over K-OMS-2 and Fe-K-OMS-2 catalysts behave similarly with that of NTP.This clearly indicates that only NTP is responsible for TCE degradation. Although the TCE conversion is much higher than that of NTP for PPC-Fe/K-OMS-2 process no CO2 yield improvement was observed in a comparison with the two other PPC configurations. However, whatever the catalyst under concern, the CO 2 yield values at 120 J/L of about 20% (Fig. 9) are higher than the C 2 yield value for NTP of about 4.6%. When the temperature of the catalyst is allowed to increase to 100 °C the physical TCE adsorption over the catalysts can now be neglected. With plasma turn off, it was noticed a CO 2 yield of 52% at 38% TCE conversion for PPC-Fe-K-OMS-2 configuration. The TCE conversion was observed to continuously increase with ED up to 88% at ED of 120 J/L while the CO2 yield globally decreases to reach an ending value of 43%. Conversely both TCE conversion and CO 2 yields increase with energy density when taking into account the two other configurations. Additionally, it is worthy to mention that CO is the main gaseous by-product of the reaction. In terms of increasing CO 2 and CO x (x = 1-2) yields the hybrid processes can be ranked as follow (Tc: 100 °C; ED: 120 J/L): PPC-K-OMS-2 (33; 52) < PPC-Fe/K-OMS-2 (40; 58) < PPC-Fe-K-OMS-2 (44; 60). When the temperature of the catalyst is allowed to vary to 150 °C it is found once more an increase of TCE conversion and CO2 yield as a function of ED in PPC-K-OMS-2 and PPC-Fe/K-OMS-2 configurations. However, the beneficial effect of temperature on TCE conversion when rising the temperature from 100 °C to 150 °C is not so clear as it is only observed for ED less and higher than 60 J/L for PPC-K-OMS-2 and PPC-Fe/K-OMS-2 processes, respectively. These results can be consistent with changes in the physical/chemical properties of the catalysts. Future work involving the study of catalyst stability in PPC configuration is necessary to establish such catalyst evolution. By opposition it is observed, at a catalyst temperature of 150 °C, a significant improvement in TCE abatement performances (TCE abatement: 78%; CO2 yield: 52%) over Fe-K-OMS-2 catalyst due to an efficient thermal activation. With plasma turn on, it is found that both TCE conversion and CO2 yield globally increase as a function of ED showing in that way the beneficial assistance of NTP. As a result, 63% of CO2 yield can be achieved for a TCE conversion close to 100%. The efficiency of the PPC process towards TCE total oxidation in a comparison with that of NTP was assessed when looking at the FT-IR spectra of both the inlet and outlet stream recorded between 700 and 1100 cm-1 and 1720-1880 cm-1, respectively, (Fig. 10a-b) at Tc of 150 °C for an energy density of 90 J/L. With plasma turn on, the TCE decomposition is revealed by the decrease in intensity of the C-H out of plane deformation band of TCE at 945 cm-1 (Fig. 10a) while ozone production from dioxygen is detected in the outlet stream by bands at 1014-1046 cm-1 [48,49]. In the 1720-1880 cm-1 FT-IR window the characteristic bands at 1790 and 1820 cm-1 can be ascribed to the presence of dichloroacetylchloride (DCAC), that at 1830 cm-1 to phosgene (PG) and that at 1780 cm-1 to trichloroacetaldehyde (TCAD) (Fig. 10b) The detection and possible reaction schemes of formation of such intermediate oxidation products have already been observed and discussed elsewhere [36,37]. In PPC configuration the intensity of the band of TCE at 945 cm-1 decreases once more to almost disappears in the case of PPC-Fe-K-OMS-2. Whatever the PPC configuration, the bands relative to O 3 and polychlorinated compounds disappear while analysis of the different FT-IR spectra shows the emergence of new bands located at 795 and 774 cm-1 characteristic of the C-Cl bond vibration relative to CCl 4 and HCCl3, respectively [36]. HCCl3 and CCl4 formations can be explained by the reaction of CHCl 2 and CCl 3 radicals resulting from the easy cleavage of the carbon-carbon bond of DCAC and TCAD with adsorbed Cl. However, the intensity of these characteristic bands is minimized in PPC-Fe-K-OMS-2 configuration showing in that way the importance of the nature of the catalyst. These above observations attest of the beneficial role of ozone to give active oxygen species over the catalyst surface enabling the production of active species prone to oxidize the plasma processed gaseous polychlorinated by-products as well as the remaining TCE owing to the formal equations:

To sum-up, the introduction of iron by co-precipitation has a significant beneficial impact on the properties of the catalyst: K-OMS-2 like structure with many defects, particles of pseudo-spherical morphology, high specific surface area and an increase of the reducibility of surface Mn 4+ . A possible interaction between Mn and Fe in the Fe-K-OMS-2 framework as well as an increase of the active site density may contribute to an easily decomposition of O3 to get active oxygen species and to enhance the catalyst surface oxygen mobility enabling to specifically oxidize the different plasma generated hazardous gaseous species such as phosgene, trichloroacetaldehyde and dichloroacetylchloride. These characteristics explain the better performances of the NTP coupled with Fe-K-OMS-2 towards TCE abatement in our experimental conditions.

Conclusion

Plasma assisted Fe-K-OMS-2 catalyst working in post-plasma configuration at a temperature of 150 °C presents high activity for TCE removal in moist air and relevant CO 2 yields. The improved performances of this material can be related to an increase of oxygen vacancies and oxygen mobility in comparison to those of the K-OMS-2 catalyst. These characteristics allow facilitating the production of active species from plasma generated ozone and the surface oxygen mobility to promote the degradation of VOC of intermediates of reaction into CO2.

Fig. 1 .

 1 Fig. 1. Schematic diagram of the PPC experimental set-up.

3 .

 3 Results and discussion 3.1. Main characteristics of the materials 3.1.1

Fig. 2 .

 2 Fig. 2. XRD patterns of the synthesized materials.

Fig. 4 .

 4 Fig. 4. Representative SEM images from (a) K-OMS-2 and (b) Fe-K-OMS-2 solid.

Fig. 5 .

 5 Fig. 5. H2-TPR profiles for the synthesized materials.

Fig. 6 .

 6 Fig. 6. (a) TGA/DTG and (b) DTA profiles as a function of temperature over the synthesized materials

Fig. 7 .

 7 Fig. 7. TCE conversion and O3 production as a function of temperature with NTP alone.

Fig. 8 .

 8 Fig. 8. TCE conversion in PPC experiments as a function of ED and catalyst temperature.

Fig. 9 .

 9 Fig. 9. CO2 yields in PPC experiments as a function of ED and catalyst temperature.

Fig. 10 .

 10 Fig. 10. FT-IR spectra between 1880 and 1700 cm-1 (a) and 1100 and 700 cm-1 (b) of inlet and outlet stream (Tc = 150 °C; ED = 90J/L; PG: Phosgene; DCAC: Dichloroacetylchloride; TCAD: Trichloroacetaldehyde).

Acknowledgments

The research has been partially supported by an Interreg V France-Wallonie-Vlaanderen project entitled "DepollutAir" and a PICS (Preparation of catalysts and catalytic depollution assisted by plasma) from CNRS is acknowledged for financial support. Chevreul Institute (FR 2638), Ministère de l'Enseignement Supérieur et de la Recherche, Région Nord -Pas de Calais and FEDER are acknowledged for supporting and funding this work. The authors are grateful in particular to Olivier Gardoll (Lille1 University, France) for the TPR analyses, Nora Djelal for SEM analysis, Laurence Burylo for XRD measurements, Dayan Chlala and Elise Bernier for Raman measurements.


Deniz Engin

Yannis Avrithis

Zero-Shot and Few-Shot Video Question Answering with Multi-Modal Prompts

Recent vision-language models are driven by large-scale pretrained models. However, adapting pretrained models on limited data presents challenges such as overfitting, catastrophic forgetting, and the cross-modal gap between vision and language. We introduce a parameter-efficient method to address these challenges, combining multimodal prompt learning and a transformer-based mapping network, while keeping the pretrained models frozen. Our experiments on several video question answering benchmarks demonstrate the superiority of our approach in terms of performance and parameter efficiency on both zero-shot and few-shot settings. Our code is available at https: //engindeniz.github.io/vitis.

Introduction

Recent vision-language models have shown remarkable progress, driven by transformer-based large-scale pretrained models [START_REF] Dosovitskiy | An image is worth 16x16 words: Transformers for image recognition at scale[END_REF][START_REF] Liu | Video swin transformer[END_REF]9,[START_REF] Liu | RoBERTa: A robustly optimized BERT pretraining approach[END_REF][START_REF] He | DeBERTa: Decoding-enhanced bert with disentangled attention[END_REF][START_REF] Radford | Language models are unsupervised multitask learners[END_REF][START_REF] Radford | Learning transferable visual models from natural language supervision[END_REF]. These models have been incorporated into video understanding methods, including video question answering (VideoQA), through multimodal fusion on large-scale multimodal datasets [41,3,[START_REF] Zellers | MER-LOT: Multimodal neural script knowledge models[END_REF]. However, adapting pretrained models to videolanguage tasks on limited data is challenging. This is because of the gap between the visual and language modalities and, more importantly, because finetuning the entire model on limited data can lead to overfitting and forgetting previously acquired knowledge.

To address the gap between modalities, transformerbased mapping networks have been employed between frozen vision and language models [START_REF] Mokady | Clip-Cap: CLIP prefix for image captioning[END_REF][START_REF] Han | AutoAD: Movie description in context[END_REF][START_REF] Alayrac | Flamingo: a visual language model for few-shot learning[END_REF]. These networks map visual features to an appropriate embedding space before they are given as input to the language models. To address overfitting, parameter-efficient adaptation methods have been explored, e.g., prompt learning [START_REF] Xiang | Prefix-Tuning: Optimizing continuous prompts for generation[END_REF][START_REF] Liu | GPT understands, too[END_REF][START_REF] Liu | P-tuning: Prompt tuning can be comparable to fine-tuning across scales and tasks[END_REF] and adapter layers [START_REF] Houlsby | Parameter-efficient transfer learning for NLP[END_REF] on frozen pretrained models. These approaches preserve the generalization of large-scale models while reducing the number of trainable parameters.

In this work, we investigate the adaptation of large-scale visual-language models to VideoQA under scarcity of training data. Inspired by FrozenBiLM [START_REF] Yang | Zero-shot video question answering via frozen bidirectional language models[END_REF], we incorporate visual inputs to a frozen language model using lightweight learnable adapter layers. Beyond that, we introduce a novel visual mapping network that summarizes the video input while allowing for temporal interaction, inspired by [START_REF] Mokady | Clip-Cap: CLIP prefix for image captioning[END_REF][START_REF] Jaegle | Perceiver: General perception with iterative attention[END_REF]. In addition, we introduce multimodal prompt learning, which diminishes the number of stored parameters when finetuning in the few-shot setting. We call our model VideoQA with Multi-Modal Prompts (ViTiS).

We pretrain trainable parameters of ViTiS, i.e. visual mapping network, adapter layers, visual and text prompts, under the masked language modeling (MLM) objective on video-text pairs collected from the web, while the vision and language models are kept frozen. We evaluate ViTiS in the zero-shot and few-shot settings. For the latter, we finetune the model on downstream VideoQA tasks, using two approaches: (i) fine-tuning all trainable parameters, which are 8% of the total model parameters, (ii) fine-tuning only the prompts, which are 0.8% of all trainable parameters and a mere 0.06% of the total model parameters.

Our extensive experimental results on multiple openended VideoQA datasets demonstrate that ViTiS outperforms prior methods while requiring fine-tuning of only a few parameters for each dataset in few-shot settings. In addition, our visual mapping network contributes to better alignment and understanding of multimodal inputs, improving performance in both zero-shot and few-shot settings.

Our contributions can be summarized as follows:

1. We introduce multimodal prompt learning to few-shot VideoQA for the first time, fine-tuning as low as 0.06% of model parameters on downstream tasks. 2. We introduce a visual mapping network to VideoQA, mapping video input to the text embedding space, while supporting temporal interaction. 3. We experimentally demonstrate the strong performance of ViTiS on multiple VideoQA datasets in both zero-shot and few-shot settings.

Related Work

Video question answering Recent advances in visionlanguage models benefit from pretrained foundation models, including vision-only [START_REF] Dosovitskiy | An image is worth 16x16 words: Transformers for image recognition at scale[END_REF][START_REF] Liu | Video swin transformer[END_REF] language-only [9, [START_REF] Liu | RoBERTa: A robustly optimized BERT pretraining approach[END_REF][START_REF] He | DeBERTa: Decoding-enhanced bert with disentangled attention[END_REF][START_REF] Radford | Language models are unsupervised multitask learners[END_REF] and vision-language [START_REF] Radford | Learning transferable visual models from natural language supervision[END_REF]. Recent video understanding methods, including VideoQA, incorporate these models by leveraging large-scale multimodal data [41, 3, 60] with different pretraining objectives, e.g., masked language modeling, masked image modeling, or predicting the next word, to perform single or multiple vision-language tasks [START_REF] Sun | VideoBERT: A joint model for video and language representation learning[END_REF][START_REF] Li | HERO: Hierarchical encoder for video+ language omni-representation pre-training[END_REF][START_REF] Lei | Less is more: Clipbert for video-and-language learning via sparse sampling[END_REF][START_REF] Fu | Violet: End-to-end video-language transformers with masked visual-token modeling[END_REF][START_REF] Yang | Just ask: Learning to answer questions from millions of narrated videos[END_REF][START_REF] Zellers | MER-LOT: Multimodal neural script knowledge models[END_REF][START_REF] Li | Align and prompt: Video-and-language pre-training with entity prompts[END_REF][START_REF] Yang | Zero-shot video question answering via frozen bidirectional language models[END_REF][START_REF] Alayrac | Flamingo: a visual language model for few-shot learning[END_REF][START_REF] Zellers | MERLOT Reserve: Neural script knowledge through vision and language and sound[END_REF][START_REF] Cheng | VindLU: A recipe for effective video-and-language pretraining[END_REF][START_REF] Jinpeng | All in one: Exploring unified video-language pre-training[END_REF][START_REF] Li | Lavender: Unifying videolanguage understanding as masked language modeling[END_REF][START_REF] Huang | Clover: Towards a unified video-language alignment and fusion model[END_REF][START_REF] Fu | An empirical study of end-to-end video-language transformers with masked visual modeling[END_REF].

Adapting pretrained vision-language models to downstream tasks relies on fully supervised fine-tuning on VideoQA datasets in general [START_REF] Tapaswi | MovieQA: Understanding stories in movies through question-answering[END_REF][START_REF] Xu | Video question answering via gradually refined attention over appearance and motion[END_REF][START_REF] Jang | Tgif-QA: Toward spatio-temporal reasoning in visual question answering[END_REF]29,[START_REF] Yu | Activitynet-QA: A dataset for understanding complex web videos via question answering[END_REF][START_REF] Li | HERO: Hierarchical encoder for video+ language omni-representation pre-training[END_REF][START_REF] Garcia | KnowIT VQA: Answering knowledge-based questions about videos[END_REF]. Few recent works address the challenge of limited data by focusing on zero-shot [START_REF] Yang | Just ask: Learning to answer questions from millions of narrated videos[END_REF][START_REF] Yang | Learning to answer visual questions from web videos[END_REF][START_REF] Yang | Zero-shot video question answering via frozen bidirectional language models[END_REF][START_REF] Alayrac | Flamingo: a visual language model for few-shot learning[END_REF][START_REF] Zellers | MERLOT Reserve: Neural script knowledge through vision and language and sound[END_REF][START_REF] Li | BLIP: Bootstrapping language-image pre-training for unified vision-language understanding and generation[END_REF][START_REF] Li | Lavender: Unifying videolanguage understanding as masked language modeling[END_REF] and fewshot [START_REF] Yang | Zero-shot video question answering via frozen bidirectional language models[END_REF][START_REF] Alayrac | Flamingo: a visual language model for few-shot learning[END_REF] open-ended VideoQA tasks. Our work is similar to [START_REF] Yang | Zero-shot video question answering via frozen bidirectional language models[END_REF] in leveraging a frozen video encoder and language model with adapter layers. Beyond that, we introduce a transformer-based visual mapping network between the two models, allowing for temporal interaction. In addition, we incorporate multimodal prompt learning, allowing for efficient fine-tuning in few-shot settings.

Parameter-efficient training

As the size of large-scale pretrained models grows, adapting them efficiently on limited data without overfitting in an emerging research problem. A common solution is adapters, introduced by [START_REF] Houlsby | Parameter-efficient transfer learning for NLP[END_REF] and employed for vision-language tasks [START_REF] Eichenberg | MAGMAmultimodal augmentation of generative models through adapter-based finetuning[END_REF][START_REF] Yang | Zero-shot video question answering via frozen bidirectional language models[END_REF][START_REF] Sung | Vl-adapter: Parameter-efficient transfer learning for vision-and-language tasks[END_REF].

Another common solution is prompting, referring to inserting tokens to the input to guide pretrained models on downstream tasks. Prompts can be handcrafted (discrete) [START_REF] Brown | Language models are few-shot learners[END_REF] or learned (continuous vectors) [START_REF] Xiang | Prefix-Tuning: Optimizing continuous prompts for generation[END_REF]. Pretrained language models demonstrate remarkable generalization to zero-shot settings with handcrafted prompts [START_REF] Brown | Language models are few-shot learners[END_REF]. Prompt learning is introduced initially in natural language processing tasks [START_REF] Xiang | Prefix-Tuning: Optimizing continuous prompts for generation[END_REF][START_REF] Lester | The power of scale for parameter-efficient prompt tuning[END_REF][START_REF] Liu | GPT understands, too[END_REF][START_REF] Liu | P-tuning: Prompt tuning can be comparable to fine-tuning across scales and tasks[END_REF]43,[START_REF] Karimi Mahabadi | PERFECT: prompt-free and efficient few-shot learning with language models[END_REF] and subsequently adopted in vision [START_REF] Jia | Visual prompt tuning[END_REF][START_REF] Bahng | Exploring visual prompts for adapting largescale models[END_REF] and vision-language models. In the latter case, prompts are introduced to text encoders [START_REF] Zhou | Learning to prompt for vision-language models[END_REF][START_REF] Zhou | Conditional prompt learning for vision-language models[END_REF], or both text and vision encoders [START_REF] Uzair Khattak | MaPLe: Multi-modal prompt learning[END_REF][START_REF] Syed Talal Wasim | Vita-CLIP: Video and text adaptive clip via multimodal prompting[END_REF][START_REF] Lee | Multimodal prompting with missing modalities for visual recognition[END_REF]46], called multimodal. Learnable prompts can be inserted at the input level [START_REF] Xiang | Prefix-Tuning: Optimizing continuous prompts for generation[END_REF] and/or deep layers [START_REF] Liu | P-tuning: Prompt tuning can be comparable to fine-tuning across scales and tasks[END_REF][START_REF] Jia | Visual prompt tuning[END_REF]. Few recent works employ prompt learning for video understanding [23,[START_REF] Zhu | Uni-perceiver: Pretraining unified architecture for generic perception for zeroshot and few-shot tasks[END_REF][START_REF] Sung | Vl-adapter: Parameter-efficient transfer learning for vision-and-language tasks[END_REF] and multimodal prompt learning for video classification [START_REF] Syed Talal Wasim | Vita-CLIP: Video and text adaptive clip via multimodal prompting[END_REF]46]. We introduce multimodal prompt learning to few-shot VideoQA for the first time.

Method

The proposed method, ViTiS , is illustrated in Figure 1(a), consisting of a frozen video encoder, a visual mapping network, a frozen text embedding layer and a frozen language model that includes learnable text prompts and adapter layers. Given an input video X v , represented as a sequence of frames, and a question X q , represented as a sequence of tokens, the problem is to predict an answer X a that is another sequence of tokens. The model takes the concatenated sequence X t = (X q , X a ) as input text. Parts of X t may be masked, for example X a is masked at inference. Video encoder The input video is represented by a sequence of T frames,

X v = (x v 1 , . . . , x v T )
. This sequence is encoded into the frame features

Y v := f v (X v ) = (y v 1 , . . . , y v T ) ∈ R D×T (1)
by a frozen pretrained video encoder f v , where D is the embedding dimension.

Visual mapping network A visual mapping network f m maps the frame features Y v to the same space as the text embeddings. The mapping is facilitated by a set of M learnable visual prompts P v ∈ R D×M , which are given as input along with Y v , to obtain the video embeddings

Z v := f m (P v , Y v ) ∈ R D×M . (2)
As shown in Figure 1(c), the architecture of f m is based on Perceiver [START_REF] Jaegle | Perceiver: General perception with iterative attention[END_REF], where the latent array corresponds to our learnable visual prompts P v . It consists of L blocks defined as

Z ℓ := SA ℓ (CA ℓ (Z ℓ-1 , Y v )) ∈ R D×M (3)
for ℓ = 1, . . . , L, with input Z 0 = P v . Each block ℓ maps the latent vectors Z ℓ-1 first by cross attention CA ℓ with the frame features Y v and then by self attention SA ℓ to obtain Z ℓ . In cross attention, Z ℓ-1 serves as query and Y v as key and value. We thus iteratively extract information from the frame features Y v into the latent vectors, which are initialized by the visual prompts. The output video embeddings are

Z v = Z L ∈ R D×M .
To allow modeling of temporal relations within the video, learnable temporal position embeddings are added to Y v before f m .

Text embedding

The input text is tokenized into a sequence of S tokens, X t = (x t 1 , . . . , x t S ). This sequence is mapped by a frozen text embedding layer f t to the text embedding space,

Z t := f t (X t ) = (z t 1 , . . . , z t S ) ∈ R D×S . (4)
One or more tokens are masked, in which case they are replaced by a learnable mask token.

Language model We concatenate video and text embeddings into a single input sequence

(Z v , Z t ) ∈ R D×K of length K = M + S.
We then feed this sequence to a transformer-based bidirectional language model f to obtain an output sequence of the same length. Finally, a classifier head g maps the output sequence to logit vectors over a vocabulary U . The logit vectors coresponding to masked tokens are selected to apply the loss function at training or make predictions at inference. Both f and g are pretrained and kept frozen. However, as shown in Figure 1(b), f is adapted by means of learnable deep text prompts and adapters, described next.

f (Z v , Z t ) ∈ R D×K (5)
Text prompts To reduce the number of fine-tuned parameters at downstream tasks, we introduce attention-level text prompts in self-attention blocks at each layer of the language model, referred to as deep text prompt learning [START_REF] Liu | P-tuning: Prompt tuning can be comparable to fine-tuning across scales and tasks[END_REF]. Given a sequence Z ∈ R D×K of token embeddings as input to a self-attention layer of the language model f , we prepend two sequences of learnable text prompts P K , P V ∈ R N ×D to the key and value respectively:

Q := W Q Z K := [P K W K Z] V := [P V W V Z], (6)
where W Q , W K , W V ∈ R D×D are the query, key and value projections respectively. The output sequence length does not change since it is determined by the query, where we do not prepend prompts. There is one pair of variables P K , P V for each layer of f , collectively denoted as P t . These variables are either defined as parameters directly or parametrized by means of projections as discussed in the supplementary.

Adapters Following [START_REF] Yang | Zero-shot video question answering via frozen bidirectional language models[END_REF], we add adapter layers to the language model f . Given a sequence Z ∈ R D×K of token embeddings, an adapter layer A maps it through a bottleneck dimension d with a residual connection:

A(Z) := Z + W 2 h(W 1 Z) ∈ R D×K , (7)
where W 1 ∈ R d×D , W 2 ∈ R D×d , and h is the relu activation function. We insert an adapter module after the self-attention layer and the feed-forward layer, preceding LayerNorm in each layer of f .

Training and inference Our model is trained using the masked language modeling (MLM) objective, where one or more tokens of X t are masked and the corresponding outputs are predicted over a vocabulary U . The parameters of the visual encoder f v , text embedding layer f t , language model f and classifier head g are pretrained and kept frozen. Only the newly introduced parameters, that is, visual prompts P v , visual mapping network f v , text prompts P t and adapter layers, are optimized on video-text pairs. We then fine-tune these parameters or a smaller subset on downstream video question answering tasks, where X t = (X q , X a ) consists of a question-answer pair and masking applies to the X a only. At inference, X a is masked and the corresponding output yields a prediction. MSRVTT-QA [START_REF] Xu | Video question answering via gradually refined attention over appearance and motion[END_REF], MSVD-QA [START_REF] Xu | Video question answering via gradually refined attention over appearance and motion[END_REF], ActivityNet-QA (ANET-QA) [START_REF] Yu | Activitynet-QA: A dataset for understanding complex web videos via question answering[END_REF] and TGIF-FrameQA [START_REF] Jang | Tgif-QA: Toward spatio-temporal reasoning in visual question answering[END_REF]. Following [START_REF] Yang | Zero-shot video question answering via frozen bidirectional language models[END_REF], we use 1% of the training data for few-shot experiments. We give more details in the supplementary.

Experiments

Implementation and metrics

We use CLIP ViT-L/14 [START_REF] Dosovitskiy | An image is worth 16x16 words: Transformers for image recognition at scale[END_REF][START_REF] Radford | Learning transferable visual models from natural language supervision[END_REF] as video encoder and DeBERTa-V2-XLarge [START_REF] He | DeBERTa: Decoding-enhanced bert with disentangled attention[END_REF] as language model. We report top-1 accuracy on public test sets for all downstream tasks, except TGIF-QA where we report on the validation set unless otherwise specified. Our model uses subtitles in the input text. We give more details in the supplementary.

Ablation

We conduct an ablation study in the few-shot setting. We provide additional analysis in the supplementary.

Model design

In Table 1, we analyze the effect of different components in the model design. We observe that changing the baseline from a linear layer to our visual mapping network without adapters increases the performance by a large margin in most datasets (row 1→5). By adding text prompts to any model design (row 1→2, 3→4, 5→6, 7→8), the performance increases for all datasets. The improvement is vast in the absence of adapters.

The model design that includes a linear mapping network and adapter layers (row 3) corresponds to FrozenBiLM [START_REF] Yang | Zero-shot video question answering via frozen bidirectional language models[END_REF] trained on WebVid2M. While using only our visual mapping network and text prompts (row 6) already works better than FrozenBiLM trained on WebVid2M, we further improve performance by incorporating adapter layers: our full model (row 8) achieves the best performance overall.

Results

Zero-shot A comparison with state-of-the-art methods on open-ended zero-shot VideoQA is given in Table 2. We observe an outstanding performance of our method across different VideoQA benchmarks, despite using significantly less pretraining data compared to other methods. Our performance on ActivityNetQA [START_REF] Yu | Activitynet-QA: A dataset for understanding complex web videos via question answering[END_REF] is on par with Frozen-BiLM [START_REF] Yang | Zero-shot video question answering via frozen bidirectional language models[END_REF]. Lavender [START_REF] Li | Lavender: Unifying videolanguage understanding as masked language modeling[END_REF] employs a multi-task training approach, transforming different vision-language tasks into MLM. Reserve [START_REF] Zellers | MERLOT Reserve: Neural script knowledge through vision and language and sound[END_REF] uses GPT-3 [5] to convert questions into masked sentences. Flamingo [START_REF] Alayrac | Flamingo: a visual language model for few-shot learning[END_REF] uses a frozen auto-regressive language model trained on an extreme-scale dataset. By contrast, our method leverages a lighter frozen language model trained on 2.5M video-text pairs.

Few-shot We fine-tune our method on 1% of the training data by following [START_REF] Yang | Zero-shot video question answering via frozen bidirectional language models[END_REF], which introduced the few-shot VideoQA task in this form. Table 3 compares our method with [START_REF] Yang | Zero-shot video question answering via frozen bidirectional language models[END_REF]. We use two strategies, fine-tuning (i) all trainable parameters and (ii) only prompts. The latter works best, consistently outperforming [START_REF] Yang | Zero-shot video question answering via frozen bidirectional language models[END_REF] while diminishing the number of fine-tuned parameters. We also compare with works using in-context learning in the supplementary.

Conclusion

In this work, we explored the adaptation of large-scale pretrained vision and language models for VideoQA under scarcity of data. We introduced multi-modal prompt learning and a visual mapping network to address challenges in such adaptation. Our method consistently outperforms prior works, while requiring minimal parameter fine-tuning in few-shot VideoQA.

  Figure1: (a) ViTiS consists of a frozen video encoder f v , a visual mapping network f m , a frozen text embedding layer f t , a frozen language model f and a frozen classifier head g. Given input video frames X v and text X t , f v extracts frame features and f m maps them to the same space as the text embeddings obtained by f t . Then, f takes the video and text embeddings Z v , Z t as input and predicts the masked input tokens. (b) The language model incorporates learnable text prompts in the key and value of multi-head-attention and adapter layers after each self-attention and feed-forward layer, before LayerNorm. (c) Our visual mapping network consists of a number of layers, each performing cross-attention between learnable visual prompts and video frame features followed by self-attention.

Table 2 :

 2 Zero-shot VideoQA top-1 accuracy test sets, except TGIF-QA on the validation set. Number of pretraining data: image-text/video-text pairs. SUB: subtitle input. CLIP: CLIP ViT-L/14. Flamingo: Flamingo-80B. An extended version is given in the supplementary.

	METHOD	SUB	#TRAINING MSRVTT MSVD ANET TGIF IMG VID -QA -QA -QA -QA
	CLIP [44] RESERVE [59] LAVENDER [34]	✓	400M --20M 3M 2.5M	2.1 5.8 4.5	7.2 -11.6	1.2 --	3.6 -16.7
	Flamingo [1] FrozenBiLM [57] ✓	2.3B 27M -10M	17.4 16.7	35.6 33.8 25.9 41.9 --
	ViTiS (Ours)	✓		-2.5M 18.1	36.1 25.5 45.5
	METHOD	TRAINED #TRAINED MSRVTT MSVD ANET TGIF MODULES PARAMS -QA -QA -QA -QA
	FrozenBiLM [57]	ATP	30M	36.0	46.5 33.2 55.1
	ViTiS (Ours) ViTiS (Ours)	ATP Prompts	101M 0.75M	36.5 36.9	47.6 33.1 55.7 47.8 34.2 56.2

Table 3 :

 3 Few-shot VideoQA top-1 accuracy on test sets, except TGIF-QA on the validation set. Number of trained parameters: fine-tuned on the downstream dataset, using 1% of training data. ATP: All trainable parameters.

Acknowledgements This work was granted access to the HPC resources of IDRIS under the allocation 2022-AD011012263R2 made by GENCI.