Osama Arouk

Navid Nikaein

Kube5G: A Cloud-Native 5G Service Platform

Keywords: 5G, Cloud-Native, Mosaic5G, Kubernetes

With the proliferation of use-cases envisioned to be supported by 5G networks, the focus is not only on the performance, but also on the service agility and elasticity. Cloud native principal is a methodology of designing lightweight, isolatedcontext, and deployable at scale applications that natively exploit the features of cloud. However, supporting telco applications (e.g., 4G/5G services) in the cloud brings up many challenges, such as the coexistence of physical and virtual functions, (near) realtime resource provisioning, service continuity, and strict latency and data rates. In this paper, we propose Kube5G, as a realizable agile service platform in support of 4G/5G cloud native applications. Kube5G introduces a novel approach in building and packaging a cloud-native compliant telco network function (NF) in a form of nested well-defined layers. In addition, we present a workflow for continuous integration and development operations in support of multi-version network functions (physical, virtual and cloud functions). We also present a concrete prototype implementation of Kube5G with experimental results indicating its efficiency and highlighting user and network perceived performance.

I. INTRODUCTION

Fast, access at scale, frequent deployment of services, and quick failure recovery (e.g., service availability ≥ 99.999%) became important features to support current and novel 5G network services in divers virtualized/cloud environments. Supporting such flexibility in 5G networks as required to realize network slicing as well as service elasticity (e.g., service update/upgrade and scaling), can be achieved via softwarization, virtualization, and cloud computing technologies.

Cloud-native approach is a complete methodology to develop, build, run, and manage applications that fully exploit the cloud computing model. Cloud-native applications have three main design patterns: (1) microservices 1 , where an app may be composed of many services that are meshed and operating independently from each other, (2) containerization, where an app is packaged in one or multiple isolated containers and managed by means of a set of standard APIs, and (3) continuous integration and delivery (CI/CD), where an app goes through a fast cycles of development, build, test, release, and deployment. Twelve-factor 2 is a well-known approach for designing cloud-native software as a service (SaaS) including portability, isolation, stateless, unified and declarative APIs as a mean for inter-service communications. This paper leverages these principles in design and development of cloud-native telco applications, mainly in 4G/5G networking.

Microservices and containers are featured by small footprint, fast start time and comparative bare-metal performance, making them highly eligible for the deployment of 5G in 1 https://martinfowler.com/articles/microservices.html 2 https://12factor.net/ the (edge) cloud. There are many containerization technologies, such as linux container (LXC), Containerd, CRI-O, and Docker, with relatively similar performance 3 . However, the number of containers grows drastically on per service basis (i.e., network slices and sub-slices), which calls for an efficient 5G service management and orchestration, able to achieve the envisioned performance, scalability, and agility. Several frameworks are already exist, such as Kubernetes, Docker Swarm, and Apache Mesos. For the ease of packaging, deploying and managing Kubernetes applications, Operator framework 4 is introduced under telcoKubernetes environment to encapsulate the lifecyle management operations and thus facilitate service automation. It has to be noted that telcoKubernetes is considered as defacto candidate for the orchestration of 5G and beyond in cloud environment as it has the largest community, better support, and promising future [1]. The same also holds for Docker container model 5 .

Compared to IT applications, telco has many fundamental differences, making its adoption in the cloud a very challenging task. According to 5G-PPP [1], six fundamental telco features shall be supported in 5G. Here, we highlight the most important ones. Supporting meshing network service (as one application may be composed of many microservices) imposes the support of multiple networks per microservice. This requires extendable lifecycle management API to customize divers service operations. Telco applications and network functions (NFs) have very different behavior, some functions are light or non-real time while others are computationalintensive and/or real time, which may require particular hardware acceleration [1], [START_REF] Nikaein | Towards a Cloud-Native Radio Access Network[END_REF]. Three types of networks functions are expected to co-exist: (i) physical network functions (PNFs) that either heavily rely on hardware (or implemented in a particular hardware) or are hardware assisted (i.e., running on specific hardware for e.g. acceleration), (ii) virtualized network function (VNF) that are software implemented and thus running on generic hardware, iii) cloud native network function (CNF) that are runnable against any platform. Supporting all of these network functions (NFs) types (i.e., multiversion functions) requires the awareness of the container management framework of the underlying platform's capabilities that needs to be supported. Different from the classical cloud applications, telco applications are geographically distributed across multiple datacenters. Therefore, multi-site support is of paramount for 5G.

Previous works, as elaborated in the next section, represent extreme points in the design space and therefore have managed to only partially address some of the aforementioned objectives. In this paper, we propose a cloud native framework that is tailored to telco applications. The design of Kube5G natively supports a multi-version 5G CNF, in particular during the CI/CD process. The lifecycle management in Kube5G is automated and supports advanced operations such runtime reconfiguration, and failover. In summary, this paper makes the following contributions:

• (Section III) a realizable cloud native 5G service platform in the form of Kube5G; • (Sections IV) a novel framework for building and automating the lifecycle of 5G cloud-native NFs, as well as concrete implementation details of Kube5G based on Ope-nAirInterface (OAI), Mosaic5G, Ubuntu Snaps, Docker and Kubernetes; • (Section V) experimental evaluation of the various aspects of Kube5G highlighting its performance as well as various capabilities compared to the state-of-the-art solutions.

II. RELATED WORK In the literature, there are few works about the automation of the deployment of containerized 5G NFs. The authors in [START_REF] Amogh | A cloud native solution for auto scaling of mme in lte[END_REF] propose a cloud native solution for scaling the core network (CN) entity MME (Mobility Management Entity) for handling the control signaling overhead from Radio Access Network (RAN). The authors in [START_REF] Bolivar | On the deployment of an open-source, 5g-aware evaluation testbed[END_REF] propose a 5G-aware testbed, with the support of containers and virtual machines orchestration. Another platform in the vein of 5G is the work in [START_REF] Van Rossem | A vision for the next generation platform-as-a-service[END_REF], where the authors propose a platform as a service for the development and operation of network services. The authors claimed that the platform offers better flexibility and also lowers the barriers for unifying the broad spectrum between technologies and services in telco landscape. However, these later works do not focus on how to build and automate the lifecycle of 5G functions in a cloud environment. The focus of the authors in [START_REF] Dzogovic | Building virtualized 5g networks using open source software[END_REF] is more about how to build a 5G mobile network using the open-source OpenAirInterface (OAI), without any focus on how to build the 5G functions and automate them in a cloudified environment. With a focus on the RAN as opensource for Mobile Edge Computing (MEC) applications in the context of 5G networks, the authors in [START_REF] Haavisto | Open-source rans in practice: an over-the-air deployment for 5g MEC[END_REF] present an automated way using devops for the development and deployment of 5G MECs. However, none of these works tackle the problem of building and automating the lifecycle of 5G NFs following cloud-native computing principles. In this paper, we present a novel framework for designing and building 4G/5G cloudnative NFs and automating the lifecyle of 4G/5G network services for both RAN and Core Network (CN) domains. It is worth noting that there are many opensource projects fostering the deployment of 5G and beyond in cloud native environment, such Open-RAN (O-RAN), and Cloud Native Computing Foundation (CNCF) 6 . Further, many efforts have been made to build operational 5G testbed facilities in Europe, and US considering cloud native design patterns, namely 5G-EVE, 5G-VINI, 5G-GENESIS, EMPOWER (EU-US) and PAWR.

BareMetal

Any Cloud Virtual machine

API API

Fig. 1: High-level Architecture of Kube5G

III. KUBE5G OVERVIEW

The core contribution of this paper, Kube5G, is a novel cloud native 5G design that is inline with the spirit of CNCF and the needs of an agile, scalable, and on-demand service-oriented mobile network architecture. Being able to simultaneously satisfy (a) building and packaging cloud-native 5G NFs, and (b) runtime service automation and capability exposure in the context of 4G/5G RAN and CN, is the main, yet not resolved, challenge addressed by Kube5G. Kube5G architecture is illustrated in Fig. 1 that is composed of (from bottom to top) (i) infrastructure and Software defined resources, (ii) container orchestration, (iii) runtime execution environment, (iv) packaged cloud native applications, and (v) extensions. The architecture (ideally) supports any type of deployment, regardless whether it is baremetal, virtual machine (e.g., virtualbox), or any private/public/hybrid cloud. In order to fully optimize the resources, future data centers shall support full disaggregation and abstraction of resources [START_REF] Han | Network support for resource disaggregation in next-generation datacenters[END_REF]. The container orchestration acts as both infrastructure manager, i.e. cloudnative infrastructure manager (CIM), and application manager, i.e. cloud-native network function manager (CNFM) [START_REF][END_REF]. Thus the container orchestration is responsible of controlling infrastructure resources like compute and networking. Like virtualized infrastructure manager [START_REF][END_REF], CIM has many responsibilities/functionalities, such as orchestrating the allocation/upgrade/release/reclamation of resources (including resources' optimization), and managing the mapping of virtualphysical resources. As CNFM, container orchestration is responsible of i) CNF instantiating and (pre)configuration, ii) CNFM software update and/or upgrade/downgrad (whenever needed) and CNF scaling, iii) CNF automated healing and termination and lifecycle management change notification and monitoring [START_REF][END_REF]. Kube5G supports the co-existance of both VNF and CNF as currently required for 4G/5G NFs. VNF is any virtual function not developed to be cloud native compliant, which are generally monolithic functions or environments and/or hardware-dependent NFs or entities. In order to allow VNFs to be executed in a cloud native environment (e.g., Kubernetes), the runtime execution environment is needed, such as Virtlet and Kubevirt. As detailed later in the design of a cloud-native application, supporting APIs as binding ports is important for CNFs for communications between services, as well as remote interactions with them. Further, packaging the application with software development kit (SDK) and APIs in containers provides agility, isolation and portability, and thus the operability against any platform. In this context, SDK is a set of layers decoupling an application from its data, tools, and hooks, and provide specific functions and methods to be accessed through one or more API calls (Fig. 2).

Finally, the extensions play an important role in Kube5G, in order to support many value added functionalities. Examples of such extensions are: (i) management and orchestration (MANO) like OSM, (ii) monitoring and network intelligence like kubeflow7 , (iii) cloud native network deployment and automation via Kube5G-Operator8 that is openshift operator.

IV. KUBE5G DESIGN AND IMPLEMENTATION

A. cloud native-compliant network function (NF) design

Fig. 2 illustrates the proposed novel design of a cloud-native NF as a set of nested layers, compliant with the twelve factor methodology. Layers are loosely coupled with each other to allow independent lifecycle management process to occur. Similar in spirit with Docker, the nested-layer design allows reusability across layers. This is of paramount importance in cloud environment to (a) minimize application update/upgrade time due to CI/CD, (b) retain service continuity when updating/upgrading the application by keeping application data outside of the sandbox, and (c) allow application portability across different execution environments. In the following, we present each layer separately.

Sandbox: isolates the application from its runtime execution environment and grant access to resources required for proper operation of the app (e.g., analogy with Android and IOS apps). It is a self-contained package, where all application's dependencies are embedded, thus achieving application portability. Snap9 is a good example of sandbox. As illustrated in Fig. 2, the sandbox contains i) the application, ii) its library and binary dependencies, iii) frontend as a value added services such as versioning, capabilities, monitoring and configuration APIs, exposed by the application.

App Data: stores all the application-specific data required for service elasticity (e.g., redeployment, scalability). It includes credentials, configuration, and runtime stats and logs stored across different app revisions. Application frontend is in charge of maintaining App Data. Such a decoupling makes the application stateless and thus significantly improves the efficiency of lifecycle management processes.

Utils and Hooks: Utils are a set of helper tools that are needed inside the container to perform runtime testing or monitoring of the application. They are used to realize service scalability and agility (e.g., monitoring the load and scaling up/down the resources). On the other hand, Hooks are in charge of application lifecycle management inside the container, such as application restarting, (re)configuration, or sandbox upgrading.

Container: is a software package containing everything required to run the application properly. Different from Sandbox, Container includes system tools, libraries, and settings, thus making the software completely independent of the system on which the application is running. One of the main important features of Container is its elasticity, where many instances of the same application can be run on the same host, or being distributed over many environments. Container supports two types of ports: (1) binding ports needed to connect to external applications as service producer/consumer for the purpose of logging and monitoring (e.g., flask and OpenAPI), and (2) meshing service needed to connect to external applications and share states for a proper operation of the embedded application (e.g., database). This port is also used to store the App Data outside of the container when needed (e.g., container upgrade or failover).

B. CI/CD Workflow

Fig. 3 illustrates the proposed workflow of continuous integration and deployment in support of 4G/5G NFs. All the different versions of NFs (i.e., PNF, VNF, and CNF) are supported in this workflow. The workflow starts when there is a change/update in the project (application), where these changes are pushed to the version control (e.g., git/gitlab) that will trigger an automatic testing of the change/update (e.g., jenkins), which in general includes run/build/test the code. After successfully testing the code and if the application exists in a form of PNF (i.e., it needs to run on specific hardware like accelerator), the application is pushed to PNF registry. After that, this PNF function will be registered in the PNF catalog of management framework (MF). MF is the orchestration framework that manages and orchestrates the deployment of multi-version functions in the underlying cloud infrastructure [1]. Note that for the other type of PNF function, i.e. functions implemented as hardware, it is assumed that they are already registered in the PNF catalog when the underlying platform exposes its capabilities (Fig. 3). The next step is to create the sandbox version (refer to Fig. 2) of VNF by passing the NF to sandboxing operation. Similarly, the sandbox version of the application will be registered in sandbox registry (e.g., pushing the new version of sandboxed app to snapcraft store), and MF will register this function in the VNF catalog. The Fig. 3: Kube5G CI/CD workflow final step is to containerize the application (refer to Fig. 2) by passing its sandbox version into containerizing operation, and then push it to the container registry. The containerization is done using one of the containerization technologies such as Docker or Mesos. Finally, this function will be registered in the CNF catalog of MF.

C. CNF implementation

We realize 4G/5G CNF implementation by leveraging Ubuntu Snap as a sandboxing technology, Linux shared memory to store app data, docker hooks and python libs to manage the application, and Docker to containerize the Mosaic5G NFs. Since Mosaic5G functions 10 are sandboxed in snap version, we exploit them to build the Docker containers. Notice that the OAI source code used to build the Mosaic5G snaps is developed following Devops principles 11 . Docker provides two ways to run an application: (i) get the application's Docker image from Docker's store (e.g., Docker hub), or (ii) build the Docker image of the application using Dockerfile. Dockerfile can be defined as a script file containing all the commands that a user needs to call on the commandline for doing everything to make the application runnable inside the Docker container. In order to automate the creation of Docker images using the same Dockerfile, we create build script (c.f. CNF builder in Fig. 3). The configuration and running of Mosaic5G snaps are done using hooks, which are copied inside the Docker image during build process. Note that the hooks act as an application interface (e.g., entrypoint) inside the container.

D. Operator service automation

In order to automate the application lifecycle management in runtime, we use Kubernetes and develop a Kube5G-Operator 12 on the top of Operator framework. Kubernetes introduces a powerful tool, called Custom Resource Definition (CRD), allowing users to create new types of resources. With CRD, Kube5G-Operator exposes 4G/5G network service as a single object that only exposes service-specific APIs that make sense for service providers rather than a collection of primitives like Pods, Deployments, Services or ConfigMaps. To this end, Kube5G-Operator implements and automates both basic (e.g. installation, configuration, and monitoring) and advanced (e.g. re-configuration, update, backup, failover, restore) operations in a form of a portable Kubernetes-native applications running inside a Kubernetes cluster. In addition, it is capable of managing complex 5G services (e.g., flexible network deployment), which is traditionally managed by administrators and their operational scripts (e.g., Ansible).

As shown in Fig. 4, the Operator utilizes what is called Controller. Multiple controllers may exist, depending on the capabilities of the Operator, to monitor a certain CRD. Considered as one of the core concepts of Kubernetes, a Controller is an entity that continuously loops on the master node of Kubernetes, while listening to the cluster for detecting any changes. If an event happens on a watched resource type like failure of a pod, a reconcile cycle will start. This is done through the reconciler object associated with the concerned controller, where every controller has a reconciler object. The output of the reconcile function will decide whether it should be run again or the reconciliation is finished. For example, a controller may listen to any changes to its pods, and makes changes if the state of pods is incorrect. On the top of the Operator lies Operator Lifecycle Manager (OLM) for managing openshift Operators like installation and update, as well as managing their associated services running across Kubernetes clusters. In order to make such automation more dynamic, we expose a set of configuration parameters to the users that facilitates runtime service reconfiguration, e.g. DNS, bandwidth, and frequency bands 13 . The capabilities currently supported by the Kube5G-Operator are: (i) deployment and release, (ii) configuration and reconfiguration, (iii) network update, upgrade, and downgrade, (iv) network re-aggregation, disaggregation, and (v) CNF monitoring (health and metrics). It has to be mentioned that the current implementation of Kube5G-Operator does not fully support the insight and autopilot features of an Operator 14 .

V. PERFORMANCE EVALUATION

In this section, we assess experimental results related to the efficiency of Kube5G platform as well as the perceived user and network performance. We used OAI and Mosaic5G platforms to deploy an operational 4G+ network that supports disaggregated RAN (i.e., flexible functional split, and in particular F1 interface). In our setup, a private cloud consisting of two powerful workstations under Ubuntu 18.04, is used. The remote radio head is built based on the USRP B210, duplexer, and antenna operating in FDD SISO mode, Band

A. Performance Metrics

We compare and analyze the lifecycle operations in a setup with OAI Snaps15 in three settings: (i) bare metal (Snap), (ii) Docker and and (iii) Kube5G-Operator. Note that Snap deployment is considered as mutable infrastructure, while Docker and Kubernetes are immutable infrastructure [START_REF] Hightower | Kubernetes: up and running: dive into the future of infrastructure[END_REF]. The three considered network setups are shown in Fig. 5, where two evaluation metrics have been considered:

Deployment and reconfiguration time: The deployment time represents both the download and provisioning time. The former is the time to download the snaps for the bare-metal case or to pull the Docker images of OAIs from Docker hub for the two other cases16 , while the later is the time to bring up the network service til the users start consuming the service. Thus the provisioning time includes the configuration time plus the deployment time. Concerning the case of snaps, it is assumed that the provision time of the snaps is done semi-automatically using different scripts that are run after the download. As for the memory footprints, sandboxed snaps and their associated Docker images are designed and built to support different deployment scenarios ranging from monolithic to disaggregated. For example, OAI-CN snap and its Docker image may act either as a standalone core network or just as one network entity such as AMF/MME (Access and Mobility Management Function/Mobility Management Entity).

Network and user experience: we consider two different measurements: (i) TCP/UDP performance using iperf3 , (ii) application level performance using nperf17 . The nperf tool includes: DL/UL rates, latency, browsing and stream performance percentage index. Note that the browse (navigation) performance reflects the loading time of different websites, while the video performance index is the ratio of loading and playing time of video to its nominal duration.

B. Results

1) Deployment and reconfiguration time: Fig. 6 shows the download, service provision, and runtime reconfiguration time, for the considered deployments. It is clear that the download time for Docker and Kubernetes is more than the double compared to that of snaps. This is because of a larger memory footprint of Docker images compared to Snaps, i.e. 528MB for CN and 745MB for RAN images versus 58MB for CN and 247MB for RAN Snaps. Although it takes about 30 seconds more to download the images, the benefit of using containers is clear when comparing with the service provision time (configuration and deployment time until connecting the UE). It can be observed from the figure that the service provisioning time is higher by a factor of 3 for snaps compared to Docker or Kube5G-Operator. Concerning Kube5G-Operator, the mean time for provisioning a service is about 1 minutes and 12 seconds, which takes (on average) 16 seconds more compared to docker. Therefore, service automation can be significantly improved using docker and Kube5G-Operator framework.

When comparing service runtime reconfiguration, it can be seen from Fig. 6 that the Kube5G-Operator is able to lower the time by a factor of 2 compared to Docker and baremetal (Snap). The main reason behind this is that the Kube5G-Operator redeploys only those entities for which a custom resources (CR) is applied (e.g., reconfiguration) while retaining the others18 , whereas Docker redeploys the whole network service. Notice that two reconfiguration times are measured for Kube5G-Operator: (i) both RAN and CN reconfiguration, and (ii) only RAN reconfiguration. In the former case, the reduction in reconfiguration time for Kube5G-Operator comes from the definition of CR that reconfigures RAN and CN without changing the HSS database (mysql in Fig. 5). It can also be observed that the Baremetal (Snaps) reconf has a lower reconfiguration time than that of Docker and very comparable time with respect to Kube5G-Operator. This is because both Docker and Kubernetes-Operator are based on an immutable infrastructure [START_REF] Hightower | Kubernetes: up and running: dive into the future of infrastructure[END_REF], and thus require to redeploy the network (fully and partially), whereas Snaps just require (manual) service reconfiguration.

It has to be noted that when a failure happens, networkwide redeployment process may be triggered for both Docker and Baremetal (Snap). Instead, Kube5G-Operator leverages CRD to recover from a failure, for example by redeploying those entities concerned by the failure19 or network autoconfiguration. Moreover, it is even very complex and not feasible to reconfigure many tens (even hundreds) of entities without breaking/degrading the service when using Baremetal (Snap) or Docker. The above results demonstrate that Kube5G-Operator significantly improves the efficiency of service automation in terms of lifecycle management, scalability, and failover when compared to Baremetal (Snap) or Docker.

2) User and Network experiences: Fig. 7 illustrates the sustainable TCP and UDP performances. From the figure, it is Instantaneous CPU utilization when generating TCP and UDP traffics is shown in Fig. 8, where only one CPU is exploited to carry the traffic. It can be observed that the CPU utilization for TCP traffic is more fluctuating for Snap and Docker than that of Kube5G-Operator, mostly due to bidirectional behavior of TCP. The maximum CPU utilization in case for Snap is 90% (both TCP and UDP), and for Docker and Kube5G-Operator is 80% (UDP) and 85% (TCP). These results reveal also that the CPU resource utilization profile for Kube5G-Operator is more efficient and stable than that of Snap and Docker. Fig. 9 shows application level performance for the three considered deployments. Again, it can be observed that they achieve a comparative performance, with a slightly better score for Kube5G-Operator. These results confirm the feasibility of cloud native deployments of 4G/5G network service while retaining user and service perceived performance. This indicates that the 4G/5G network, and more generally telco applications, can be provided on as-a-service basis in a very short time scale exploiting service elasticity, scalablity, and agility. VI. CONCLUSIONS Cloud-native technologies are the main enabler for efficient service deployment, fast recovery, agility, elasticity, and access at scale for 5G services. In this paper, we present Kube5G as an agile service platform for supporting 4G/5G networks in

Fig. 2 :

 2 Fig. 2: Nested-layer design of cloud native-compliant NF

Fig. 4 :

 4 Fig. 4: Kube5G-Operator workflow

Fig. 5 :

 5 Fig. 5: Network topology setup 7, with 5 MHz channel bandwitdh. The user equipment (UE) is an iPhone SE.

Fig. 6 :

 6 Fig. 6: Download, Service provision, and reconfiguration times

Fig. 7 :Fig. 8 :

 78 Fig. 7: TCP/UDP traffic for the considered deployments

Fig. 9 :

 9 Fig.9: Network and User experience cloud-native environments. Kube5G proposes a novel CNF design as a nested reusable layers to ease building, packaging, and upgrading of multi-version NFs during CI/CD process. A concrete implementation of 4G/5G cloud-native functions is presented with automated lifecycle management operations using Kube5G Operator. Kube5G is benchmarked against Baremetal (Snap) and Docker deployments demonstrating its feasibility and efficiency for fast roll-out of 4G/5G network services. The results confirm that 4G/5G network can be provisioned in less than two minutes, and updated/reconfigured (as a part of autopilot feature) in less than a minute. In future, we plan to model and support natively near-realtime CNF for 5G applications and services in Kube5G.

https://kubedex.com/kubernetes-container-runtimes/

https://coreos.com/blog/introducing-operators.html

https://bit.ly/3ekwpvT

O-RAN: https://www.o-ran.org, CNCF: https://www.cncf.io

https://www.kubeflow.org/

http://mosaic-5g.io/kube5g/

https://snapcraft.io/docs/getting-started

https://hub.docker.com/r/mosaic5gecosys/oairan

https://snapcraft.io/search?q=mosaic-5g

https://hub.docker.com/u/mosaic5gecosys

iperf3:https://iperf.fr/, nperf:https://www.nperf.com

The deployment is done without scaling, i.e, there is one instance of an entity

https://bit.ly/36EeEEV, https://bit.ly/2X7jYO4

ACKNOWLEDGMENT

The research leading to these results has received funding from Davidson Consulting as well as European H2020 5G-Victori and Affordable5G projects under grand agreement 857201 and 957317.


Robert Schmidt
email: robert.schmidt@eurecom.fr

Navid Nikaein
email: navid.nikaein@eurecom.fr

Demo: Efficient Multi-Service RAN Slice Management and Orchestration

The 5G mobile network is supposed to handle a variety of services with different requirements. By means of virtualization, network slices form customized virtual networks transporting services with associated service guarantees. Especially the radio access network (RAN) requires an efficient multiplexing of multiple services onto the sparse radio resources. In this demo, we show how a RAN can be dynamically customized without service interruptions for different slices. In particular, our solution considers the slice requirements and adapts the slicing algorithm without interrupting other slices in the network. This allows an efficient resource usage while respecting isolation and performance requirements, in particular latency. Furthermore, dynamic end-to-end slicing is enabled by automatically adding core networks as required by the slice owner. Finally, this solution allows to compare different slice algorithm implementations.

I. INTRODUCTION

Network slicing is a key enabler for the service-oriented 5G network. It allows to overlay a physical network with multiple virtual networks (slices) in order to share resources efficiently while providing functional flexibility. This is driven by an increasing business aspect in which mobile network operators allow third parties such as verticals to customize a network towards their services, such as enhanced mobile broadband (eMBB) and ultra-reliable low-latency communications (URLLC).

In particular, the scarce radio resources in the radio access network (RAN) need to be shared between multiple service providers while guaranteeing isolation and allowing to customize functionality. In the last years, a number of architectures and slice algorithms have emerged. However, the realization of encapsulated slices within the RAN with support of varying quality of service (QoS) levels, in particular latency, is still an open problem. Also, experimental research possibilities for practical slicing implementations are limited. Finally, it is difficult to directly compare existing slicing algorithms since their implementation was only in simulators or over different technologies.

II. DEMO DESCRIPTION AND CONTRIBUTION

We extended our previous contribution [START_REF] Ksentini | Toward enforcing network slicing on RAN: Flexibility and resources abstraction[END_REF], [START_REF] Schmidt | Slice Scheduling with QoS-Guarantee Towards 5G[END_REF] and designed and implemented a RAN slice architecture in OpenAirInterface [START_REF] Nikaein | OpenAirInterface: A flexible platform for 5G research[END_REF] as shown in Figure 1. The customizable slice scheduler identifies the radio resources to be used by each slice according to an algorithm as detailed below. Each slice can then allocate resources to its associated users by using a custom packet scheduler. The result of possibly multiple slice allocations in a subframe is then merged and user data is jointly multiplexed onto the physical resources. A simple interface between the slice scheduler and the individual packet schedulers allows a clear separation of concern between slice resource allocation and user resource allocation, making it possible to independently design and implement the respective algorithms. Through the use of the software-defined RAN controller FlexRAN [START_REF] Schmidt | FlexVRAN: A flexible controller for virtualized RAN over heterogeneous deployments[END_REF], slices can be dynamically added, removed or modified by the help of a slice management module in the RAN controller agent. It is possible to dynamically change parameters of a slice or its packet scheduler. Also, the slice scheduling algorithm might be changed through the controller "on-the-fly" to fulfill all the slices' service level agreements (SLA). This requires the slice parameters to be mapped from one slicing algorithm to another. As an example, consider static slicing according to a percentage. This might be mapped to an equivalent rate in another algorithm. On the contrary, a latency threshold cannot be expressed with static slicing.

Using this architecture, in this demo we make the following contributions:

1) Dynamic and efficient slice management. The controller can embed new slices and modify their parameters. Furthermore, packet schedulers can be customized to suit a particular slice owner's need, allowing slicespecific scheduling strategies and taking into account service-specific performance requirements.

978-1-7281-4973-8/20/$31.00 © 2020 IEEE

2) Multiple slicing algorithms. We implemented (i) static resource reservation for each slice in every subframe, (ii) NVS [START_REF] Kokku | NVS: A substrate for virtualizing wireless resources in cellular networks[END_REF] and (iii) a QoS-sensitive (latency) slicing algorithm [START_REF] Schmidt | Slice Scheduling with QoS-Guarantee Towards 5G[END_REF]. These algorithms guarantee resource isolation to a varying degree between multiple slices. Also, this allows a fair comparison of these algorithms. 3) Description of different slice requirements. Through a descriptor, an SLA for each slice is expressed. Consider the scenario in Figure 1. Two eMBB slices are present and are multiplexed using a static slicing algorithm. A third slice owner wishes to embed a URLLC slice. The controller decides that the current static slicing is not appropriate for this scenario and switches to a QoSaware slicing algorithm which can express the latency requirements by this slice while keeping the SLAs of the two eMBB slices. 4) Encapsulation of slices. The interface between the slice algorithm and the slice packet schedulers allows a clean separation of concern with encapsulated state of each slice with respect to its users and resources. This creates network functions that can be added, removed and customized to correspond to slice owner needs without impacting the overall network. 5) End-to-end slicing. We added support to dynamically add and remove core network (CN) connections to OpenAirInterface through an S1 management module, highlighting the operational aspect of our solution. This allows to connect on demand to slice-specific dedicated CNs under the control of an orchestrator. Consider again Figure 1: the URLLC slice requires a CN with short packet handling delays. Before embedding the slice, the base station connects to CN LL before adding the slice.

III. DEMO IMPACT

Note that a number of contributions follow from this demo. The above architecture allows the research community to readily implement and evaluate algorithms for both slicing or packet scheduling [START_REF] Capozzi | Downlink packet scheduling in LTE cellular networks: Key design issues and a survey[END_REF] in a real base station, both to date rather difficult to implement in OpenAirInterface. Further, it is feasible to reimplement the Orion [START_REF] Foukas | Orion: RAN slicing for a flexible and cost-effective multi-service mobile network architecture[END_REF] architecture (of which the code has not been published) to functionally isolate slices from each other.

IV. DEMO SETUP

The demo will concentrate on the life cycle of a URLLC slice. Before adding the slice, the controller will connect the base station to an indicated CN and possibly dynamically change the slicing algorithm to a QoS-based one. Then, the URLLC slice is added in the base station. As soon as no users are active anymore, the outlined changes will be rolled back by the controller.

Users in the URLLC slice will experience an improved performance: their latency will be kept low, while an optimal system resource usage will be guaranteed. Visitors of the demo will be able to see this on a dashboard, tracing key performance indicators. We will use the demo setup illustrated in Fig. 2, consisting of LTE phones, an Ettus USRP B210-mini frontend with radio equipment, four computers and a switch. The USRP is connected to one computer running OpenAirInterface as the RAN with slicing capability and data plane functionality. Via the switch, the RAN is connected to two CNs, each being a standalone CN (consisting of HSS, MME, and S/P-GW) and connecting the end-to-end slices to the internet.

The demo is controlled from a laptop hosting the FlexRAN controller. The controller reconfigures the RAN (slicing and CN management) through the FlexRAN protocol. A dashboard on a separate screen allows the visitor to follow the demo.

Fig. 2 .

 2 Fig. 2. Demo setup. An additional screen will show the slice life cycle and slice performance indicators.

ACKNOWLEDGMENT This work received funding from the European Union's Horizon 2020 Framework Programme under grant agreement No. 762057 (5G-PICTURE), No. 761913 (SliceNet), and No. 857201 (5G-VICTORI).


Gilles Berger-Sabbatel

Yan Grunenberger

Martin Heusse
email: heusse@imag.fr

Franck Rousseau
email: rousseau@imag.fr

Andrzej Duda
email: duda@imag.fr

Interarrival Histograms: A Method for Measuring Transmission Delays in 802.11 WLANs

Traditional measurement tools are not suitable for finegrain performance evaluation of 802.11 wireless networks. To improve this situation, we have developed Interarrival Histograms, a method for measuring transmission delays based on gathering statistics of interarrival intervals at a receiving station. By measuring a sufficient number of interarrival interval samples with a clock resolution of 1 µs, the precision of estimating the mean transmission delay is well under one microsecond. Unlike other proposals, it does not require expensive custommade cards, because it uses commercially available equipment. It allows flexible measurements not only of wireless cards, but also of access points, which cannot be done with other proposed methods, unless one can instrument the access point kernel. In this paper, we describe the principles of the proposed method, derive the estimation error of measurements, and experimentally demonstrate its precision by applying it to the 100 Mb/s Ethernet. To illustrate the cases in which the method can help analyzing the complex behavior of 802.11 networks, we present measurements of several commercially available access points and wireless cards to show some anomalies and differences with the standard.

INTRODUCTION

Measuring transmission delays in IEEE 802.11 wireless networks [12] and experimentally evaluating their performance is fairly difficult. Their MAC layer relies on a set of parameters such as interframe intervals (DIFS, SIFS, AIFS), backoff slots, and the size of the contention window. Some of these parameters are constant and others are randomly chosen, but they are defined with the precision of a microsecond. Obviously, we can easily measure high level performance metrics such as throughput or fairness, but investigating how they depend on lower layers parameters is much more difficult. For example, the developers of wireless drivers for open source operating systems such as Linux or *BSD must often cope with incomplete or reverse engineered specifications so they cannot rely upon expensive tools to verify the low-level behavior of a given wireless card. An implementation of a driver can present performance problems, but the developer does not have any clue about the cause of problems. Implementing a MAC layer or modifying an existing one on a wireless card may also require sophisticated measurement tools to validate the behavior of the implementation. In all these cases, we need a method for measuring transmission delays with sufficient precision. Such a method should be simple and usable in a set up with standard hardware without requiring in depth modifications of the kernel.

During our past work on various aspects of 802.11 performance [START_REF] Berger-Sabbatel | Fairness and its Impact on Delay in 802.11 Networks[END_REF][START_REF] Heusse | Performance Anomaly of 802.11b[END_REF][START_REF] Heusse | Bandwidth Allocation for DiffServ Based Quality of Service over 802.11b[END_REF]11], we have experimentally observed different metrics such as throughput, round trip delays, or fairness, but it was always difficult to gain more insight into the behavior of different implementations of 802.11. When we wanted to implement our own access method [START_REF] Grunenberger | Experience with an Implementation of the Idle Sense Wireless Access Method[END_REF], we wondered how to measure its fine-grain performance and no existing method was suitable for this goal. To improve this situation, we have developed Interarrival Histograms, a method based on measuring statistics of packet interarrival intervals at a receiving station. The method is simple, yet powerful and does not require instrumentation of the measured wireless station, all measurements being done at the destination host or at a monitor station. A source station sends a flow of packets to a wired host connected to a 802.11 access point via a direct 100 Mb/s Ethernet link and the host timestamps packets upon arrival with the clock resolution of 1 µs. Interarrival intervals of packets are then computed, statistically processed, and finally presented in the form of a histogram to visually grasp the most frequent values of the transmission time and easily deduce some low-level characteristics of measured wireless cards. Statistical processing of the measured intervals gives an error estimation that is even lower than the clock resolution (1 µs). This fact may be surprising-obtaining such a good precision with off-the-shelf hardware is usually unbelievable, but we provide a theoretical derivation of the error estimation and experimental validation of the precision.

Our method works in two modes: it is either a wired host connected to an access point or a wireless monitor station that measures interarrival intervals. This last mode provides slightly better precision of measurements, but usually we use both to compare histograms. The paper makes several important contributions:

• We define an original method for measuring transmission delays in 802.11 wireless networks with the precision lower than 1 µs. Histograms are generated with the resolution of 1 µs. Unlike other proposals, the method does not require expensive custom-made cards, because it uses commercially available equipment. It allows flexible measurements not only of wireless cards, but also of access points, which cannot be done with other proposed methods, unless one can instrument the access point kernel.

• We derive the estimation error of measurements and show that because of a particular dependency of random variables under consideration, the estimation error decreases fairly quickly with the number of samples.

• By measuring the 100 Mb/s Ethernet, we experimentally demonstrate the surprising precision of the proposed method.

• To show its usefulness in the context of 802.11 wireless networks, we measure several commercially available access points to see how they conform to the 802.11 specifications and analyze the behavior of several wireless cards.

Note that the method concerns transmission delays over a 802.11 link so it focuses on MAC layer characteristics and can only implicitly capture some physical layer effects when they influence the transmission delay (collisions, retransmissions due to channel errors, influence of channel contention etc.). It can measure transmission delays under adverse channel conditions, but it is not intended to measure strict physical characteristics such as signal strength, interference, or the influence of hidden nodes.

The paper is organized as follows. Section 2 overviews the related work. Section 3 describes the principles of the proposed method, derive the estimation error, and experimentally validate its precision. In Section 4, we report on measurements of several wireless cards and evaluate the influence of some system parameters such as processor speed and interrupt frequency. In Section 5, we illustrate how the method can be used by measuring several commercially available access points and wireless cards. Section 6 concludes the paper.

RELATED WORK

An overwhelming part of research work on wireless networks validates new concepts or protocols with simulation. However, even widely used simulators such as NS2, OPNET, or GloMoSim do not provide sufficiently realistic models of complex wireless behavior and their results may significantly differ for the same problem [START_REF] Cavin | On the Accuracy of MANET Simulators[END_REF]. Experimental evaluation of wireless ad hoc networks also shows that much of the theoretical work on wireless protocols is based on wrong assumptions [START_REF] Kotz | Experimental Evaluation of Wireless Simulation Assumptions[END_REF]. But precise measurement of wireless cards, access points, or experimental prototypes is not that easy and usually researchers confine themselves to simple measurements of the throughput and the round trip time.

In our previous work, we have tried to find new aspects of 802.11 performance by experimenting with available cards, for instance, the discovery of the Performance Anomaly [START_REF] Heusse | Performance Anomaly of 802.11b[END_REF], in which a station transmitting with a low bit rate limits the performance of faster stations, came out from a measurement session. Based on many such experiments, we have begun to look for a method for precise measurement of transmission times and finally developed the proposed method of Interarrival Histograms.

There are several similar recent attempts. Bianchi et al. have developed a hardware platform based on custom-made FPGA wireless cards for precise measurements of 802.11 WLANs [START_REF] Bianchi | Experimental Assessment of the Backoff Behavior of Commercial IEEE 802.11b Network Cards[END_REF][START_REF] Stefano | An Experimental Testbed and Methodology for Characterizing IEEE 802.11 Network Cards[END_REF]. Their cards can record time with the resolution of 50 ns, generate any kind of frames even invalid ones, and operate in a way that violates the standard specifications. They thus obtain interesting results by testing how commercially available cards perform and react to a non-standard behavior, for instance they inject invalid frames and observe whether a tested card waits for the EIFS period. This approach to measurements is limited to testing wireless cards-measuring access points is not possible. Our method achieves a similar measurement precision without the need for difficult to develop custom-made FPGA cards. However, in our approach, we are not able to inject non-standard frames, because we use commercially available cards.

Dangerfield et al. used a measurement set up at the sender side for analyzing the behavior of an EDCA implementation [START_REF] Dangerfield | Testbed Evaluation of 802.11e EDCA for Enhanced Voice over WLAN Performance[END_REF]. The precision of measurements was around 10 µs thus allowing the authors to measure the throughput and the mean delay with sufficient accuracy for evaluating the impact of EDCA parameters on performance. They further improved their method by taking advantage of timestamping on wireless cards to achieve the precision of 1 µs [START_REF] Malone | Verification of Common 802[END_REF] (we also use this feature of some wireless cards). This work presents the results of measurements as histograms in a form similar to ours. The main difference with our method is that they measure the transmission time on the sender station, while we do so at a receiving wired host or at a monitor station. In this way, we are able to measure the performance of commercial access points, while their set up can only measure a wireless card plugged into a instrumented PC running Linux.

Finally, we want to mention other standard measurement approaches based on clock synchronization. If two synchronized stations can measure time with high precision, obtaining statistics on transmission times is straightforward [START_REF] Fraleigh | Packet-Level Traffic Measurements from the Sprint IP Backbone[END_REF]. Time synchronization can be achieved by using stations with GPS devices, but such an instrumentation may be expensive and is only justified for long distances. In indoor situations, one can connect wireless stations in a closed neighborhood by an additional cable, but it requires instrumentation of their hardware to synchronize clocks.

To summarize, we do not claim that using histograms is new, because several papers already visualized measurement results in this way, nor reporting on backoff characteristics of commercially available 802.11 wireless cards. We think that the principles of our method are original and it presents the advantage of only requiring cheap off-the-shelf hardware to measure with high precision what cannot be measured by other methods (e.g. commercial access points).

PRINCIPLES OF THE METHOD

Our goal is thus to define a method for measuring transmission delays that only requires recording timestamps in the kernel or on a wireless card with a microsecond resolution on a receiving station.

Principles

To understand the method, let us start with the description of the measurement set up. Figure 1 presents the details of the configuration: a wireless station communicates with a wired host through an 802.11 access point in the infrastructure mode and a direct 100 Mb/s Ethernet link. A home-made application tool composed of a client and a server similar to iperf generates a continuous stream of UDP packets of a given rate and size to the destination: such a traffic source keeps the buffers on the network interfaces full so that it sends them as soon as the MAC layer allows to do it. Traffic can be sent either from the wireless stations to the wired host, if we intend to test the wireless card, or in the opposite direction if we want to test the access point. Traffic is captured and analyzed either at the monitor station or at the destination station. The former can give more precise results at the price of a slightly more complex setup. We have developed a program based on the pcap library that captures packets and records the interarrival intervals of packets. It controls the instant of storing measurements on disk to avoid I/O operations during the capture. Figure 2 illustrates the principle of measurements based on Interarrival Histograms. We want to measure T t , the overall transmission time of a data frame that includes all the overhead: interframe intervals (DIFS, SIFS, AIFS), the backoff, and the transmission times of the data and ACK frames. Note that usually the transmission time to estimate starts with the DIFS interval and ends with the reception of an ACK. However, as our method is based on the intervals measured at the receiving host, T t to estimate in our method corresponds to the interval presented in Figure 2. If we gather a large number of samples, the both definitions of the transmission time are equivalent.

Figure 2 presents the sequence of events when we measure the arrival instants at the wired host. The source wireless station generates a packet to the wired host and sends it to the access point in a data frame after the DIFS delay and the backoff interval chosen from the contention window CW. The frame is received by the access point and retransmitted on the Ethernet interface after some delay δ 1 . The access point confirms the reception of the data frame with an ACK sent to the source station. The Ethernet frame (denoted by E in the figure) arrives at the wired host and after some delay δ 2 the network driver timestamps the packet with instant t 1 . The same sequence of events repeats for the next packet timestamped with instant t 2 upon arrival. As we measure the transmission time on short distances (several meters), we neglect the propagation delay.

In our measurement set up, we have carefully considered the problem of precise timestamping of packets. Upon reception of a frame, the network interface generates an interrupt. The network driver gets the frame, record the instant of its reception with the resolution of 1 µs, and passes it to the pcap library. Timestamping is done in the kernel space so that it is not biased by random delays that might occur when timestamping is performed in the user space: the only delay involved in timestamping is the interrupt processing time, which has small jitter on a lightly loaded machine (a few microseconds). However, jitter may increase if the card generates too many interrupts, which may happen for small packets. In some configurations, it is also possible to get a timestamp set by the hardware of the network interface as soon as the frame is received (i.e. before any software processing), which can even lower the variability of delay δ 2 .

To see how we are able to estimate T t , the overall transmission time, consider the following relations:

t 1 = θ 1 + δ 1 1 + T E + δ 2 1 , (1)
and

t 2 = θ 2 + δ 1 2 + T E + δ 2 2 , (2)
where T E is the transmission time of the data frame on the Ethernet. We assume that compared to other sources of delay variability such as δ 1 and δ 2 , the transmission time on the Ethernet link can be considered as constant. We measure T m , the difference between the consecutive timestamps corresponding to the reception of packets:

T m = t 2 -t 1 = θ 2 -θ 1 + δ 1 2 -δ 1 1 + δ 2 2 -δ 2 1 , (3)
which yields

T m = T t + δ 1 2 -δ 1 1 + δ 2 2 -δ 2 1 , (4)
We can observe that

E(T m ) = E(T t ), (5)
because the differences in δ 1 and δ 2 cancel out. Moreover, the variance of the measured interval is

V ar(T m ) = V ar(T t ) + V ar(δ 1 ) + V ar(δ 2 ), (6)
where V ar(δ 1 ) and V ar(δ 2 ) are variances of the retransmission delay at the access point and of the time needed to intercept a packet and assign a timestamp, respectively. We can see that by only timestamping the arrival of packets at the receiving station, we can estimate the variable transmission time on the 802.11 link even if several delays add to the total transmission time. Figure 3 presents the sequence of events when packets are captured by a monitor station. As previously, the source wireless station sends a data frame to the access point, which is overheard by the monitor station set into the promiscuous mode. The frame is received by the access point and confirmed with an ACK frame. The access point retransmits the packet on the Ethernet to the wired host (not shown in this diagram). The monitor station timestamps the frame with instant t 1 after some delay δ 3 . The same sequence of events repeats for the next packet timestamped with instant t 2 . In a similar way, we can derive the relation:

T m = T t + δ 3 2 -δ 3 1 . (7)
So, the mean is

E(T m ) = E(T t ), (8)
as well as the variance

V ar(T m ) = V ar(T t ) + V ar(δ 3 ), (9)
where V ar(δ 3 ) corresponds to the variance of the time needed to intercept a packet and assign a timestamp on the monitor station. Our experiments show that this method is more precise than recording timestamps at the wired host, however only some types of wireless cards provides sufficient characteristics for obtaining good precision.

Precision

Let us evaluate the precision of the method for measuring T t in the last set up (measurements at the monitor station). We will focus on estimating the inherent error of the measurement method, so we assume in this section that T t is constant. Denote by

x i = T t + δ i+1 -δ i , i = 1, . . . , n (10)
sample i of the measured transmission time T m1 in a sequence of n measurements. Let us assume that

δ i = δ min + d, (11)
where δ min is a constant and d is normally distributed with mean µ and standard deviation σ: N (µ, σ).

We assume that σ is small compared with δ min so that δ i is a good approximation of a positive random variable. We consider the estimator of the partial mean

x = 1 n n i=1 x i = T t + 1 n n i=1 (δ i+1 -δ i ), (12)
to obtain

x = T t + δ n+1 -δ 1 n , (13)
because all intermediate terms cancel out. δ n+1 and δ 1 are independent normal random variables, so the distribution of δ n+1 -δ 1 is also normal with parameters N (0, √ 2σ). Thus, the estimator of the mean also follows the normal distribution:

x ∼ N (T t , √ 2σ n ). ( 14
)
We can find the confidence interval for the partial mean by considering random variable

x -T t √ 2σ n, (15)
which is normal with parameters N (0, 1). So we obtain

P (x -≤ T t ≤ x + ) = 1 -α, (16) where
= √ 2σ n K α/2 . ( 17
)
For α = 0.003 (99.7% confidence level), constant K α/2 = 3 and we obtain the following error estimation of the partial mean:

= 3 √ 2σ n . (18)
Even if we cannot take advantage of this error estimation for our method, because in general we do not know σ, it is interesting to see that the error quickly decreases in function of n-the usual increase of precision with an increasing sample size (function of 1/ √ n) becomes here 1/n, because samples x i are not independent.

As x i are not independent random variables, we cannot directly apply standard methods for finding the confidence interval for all measurements. Rather, we will construct a series of partial mean estimations for N sequences of measurements that we consider independent:

xj , j = 1, . . . , N. (19)
Let us define the estimators of the mean and the variance

X = 1 N N j=1 xj , S2 = 1 N N j=1 (x j -X) 2 . ( 20
) Random variable X -T t S √ N -1 (21)
has the Student t distribution with N -1 degrees of freedom and we can derive the confidence interval as

P ( X -≤ T t ≤ X + ) = 1 -α, (22) where =
S √ N -1 t α/2,N -1 . (23)
For large N and α = 0.003 (99.7% confidence level), t α/2,N -1 = 3 and we obtain the following error estimation of our method:

= 3 S √ N -1 . ( 24
)
This last estimation means that the precision of our method can be made arbitrarily good by increasing the number of sequences N , if the estimation of the standard deviation S is finite. The set up with measurements at the wired host can also benefit from similar precision, however the error estimation of the partial mean will now include the standard deviations of delays δ 1 and δ 2 . Then, the estimators defined in Eq. 20 applied to the series of N partial means give us the desired error estimation according to Eq. 24.

Validation

To validate our method and evaluate its precision, we have applied it to the case in which the transmission time is well known and almost constant: the 100 Mb/s Ethernet. In the experiment, the Ethernet cable directly connects two stations (no switch in between), so that the MAC delay is almost constant and the only variable part comes from random delays introduced by capturing and timestamping a packet (δ 2 ). This corresponds to the case for which we have derived the error estimation in the previous section.

For a packet of l bytes, the transmission time in the experiment should be

T t = (l + 42) × 0.08 + 1.92 µs, ( 25
)
where 42 is the size of the UDP/IP/Ethernet headers in bytes, 0.08 is the transmission time of one byte, and 1.92 is the constant overhead of the Ethernet MAC layer (preamble, CRC, and interframe interval). Figure 4 shows the histograms of the transmission times for packet sizes of 200, 400, ..., and 1400 bytes. We generate the histograms with the resolution of 1 µs. Each histogram corresponds to the observation of around 100,000 packets of a given size with N = 1200 sequences of n samples with n varying between 50 to 100. We can observe seven sharp peaks of 3 µs width.

Table 1 presents the detailed results with the estimation of the error:

• Computed transmission time (Eq. 25),

• Histogram peak instants,

• Mean measured transmission time ( X),

• Difference between the computed and measured interval,

• Estimated standard deviation ( S),

• Error estimation ( , Eq. 24).

We can observe that the estimated mean of the measured transmission times is equal to the computed transmission time up to the rounding error (all computations were done with 3 significant figures after decimal point). Moreover, the error estimation based on Eq. 24 is equal to 1ns, which is very small, because we used fairly large number of sequences N . The positions of peaks correspond to the computed and measured values up to the clock resolution of 1µs. These measurements confirm our analysis of the precision in Section 3.2. The good precision of the method comes from the fact that we do not measure a single interval, but a series of intervals. Thus, the mean can be estimated with a very good precision, even better than clock resolution, because of the quick decrease of the estimation error in function of n. The positions of histogram peaks can also be used as estimations of the transmission time, but with the precision of clock resolution.

Having validated the method for almost constant transmission times of the Ethernet, we want to apply it to transmission over 802.11 wireless links. The transmission times in this case follow a complex distribution with several peaks basically corresponding to the values of random backoff. Instead of computing the estimations of the mean and the variance, we use histograms that allow us to visually grasp the most frequent values of the transmission time and infer some characteristics of tested wireless cards. Still the precision of histograms is around 1µs, which is sufficient for our purposes. Thus, in the rest of the paper we present the measurement results of 802.11 wireless networks in form of histograms.

TUNING OF THE METHOD

We have experimented with our method to analyze the influence of some configurations or system parameters on its precision. In particular, we have tested wireless cards for the use on the monitor station and evaluated the influence of processors with different speed and various frequencies of kernel interrupts on the method.

We have used the measurement configuration as presented above (cf. Figure 1). If not stated otherwise, we use the Netgear-Prism GT card at the source station, because it follows fairly closely the specification of the 802.11 standard. The wired host is a workstation with an Athlon XP 2400+ processor running Linux FedoraCore 6 (kernel 2.6.18). Wireless stations are laptops with a Pentium Core 2 Duo, running Linux FedoraCore 6.

All measurements are done in a residential area without any other 802.11 network in favorable transmission conditions-wireless stations are close to the access point (2 m). This does not mean that the method cannot be used for analyzing performance behavior of 802.11 networks in adverse channel conditions, we simply limit the reported results in this paper to good channel conditions. Each histogram results from a session of 50,000 to 100,000 captured packets. The size of the UDP payload is 1472 bytes to fit the maximum Ethernet frame size.

Wireless cards as a monitor

We have first compared the results obtained from the capture at the wired host with measurements done at the monitor station with timestamping done in the kernel.

Figure 5 present the histograms of T m for the D-Link-Atheros card 2 measured by a monitor station and the wired host. It contains 16 regularly spaced similarly shaped peaks. The distance between the first and the last peak is 135µs corresponding exactly to 15 slots of 9µs (802.11g). The first peak appears at 330µs, which is 4µs more than the expected value (326.04µs, cf. the grid in the background corresponding to the values defined in the 802.11g standard).

We can see that both histograms show the same values of peaks, however the histogram gathered at the wired host is a little bit wider, which comes from a slightly greater variability of delays: δ 1 and δ 2 with respect to δ 3 .

2 We identify wireless cards by giving its manufacturer (D-Link) and the name of its chipset (Atheros). Figure 6 shows the histograms measured by the Netgear-Prism GT card at the monitor and at the wired host. We can see that they do not correspond, which means that we cannot use this card at the monitor, because the processing time of frames is too variable, if timestamping is done in the kernel.

Figure 7 presents a similar histogram for the Intel Centrino-IPW2915 card. The 12 last peaks are regular and corresponds well to the capture at the wired host, however the first 4 peaks are fairly distorted. From these tests, we can conclude that only the D-Link-Atheros card offers sufficient characteristics for the use at the monitor station, if timestamping is done in the kernel. the D-Link-Atheros wireless card, the same driver madwifi-ng, and run the same operating system (Linux Fedora Core 5):

Influence of the processor

• A: a Dell laptop with Pentium M at 1.7 GHz,

• B: a HP Omnibook Xe4500 laptop with Pentium IV M at 1.7 GHz,

• C: a HP Omnibook Xe3 laptop with Pentium III M at 800 MHz.

The slightly wider peaks of the laptop probably come from the difference between the architecture of Pentium III and Pentium IV. We can see that the histograms correspond fairly well, so that the processor speed does not have much influence on capturing and timestamping packets. We have tested our method for different values of the kernel variable HZ that defines the frequency of timer interrupts of 1/HZ s. Figure 9 shows the histograms for three values of HZ. We have obtained the best results for HZ= 100 as show the details in Table 2.

In each case, there is still a small proportion of intervals which fall outside of the histogram peaks. The Linux kernel does not provide support for realtime and for various reasons, the interrupts generated by the reception of a packet may sometimes be processed with a delay that can exceed one slot, as can be seen by examining the shape of the first and the last peak.

Timestamping on the wireless card

Two wireless cards (Netgear-Prism GT and D-Link-Atheros) offer the possibility of obtaining the timestamp associated by the hardware with the reception of a frame. Figure 10 shows the histogram based on this functionality obtained when both monitor and test stations use the Netgear-Prism GT card. It is fairly precise with a difference of 0.5 µs with respect to the middle of a peak. We can see 16 small peaks beginning at 362 µs that correspond to some packets sent at the bit rate of 48 Mbit/s. Capturing this behavior was not possible when using timestamping in the kernel.

Figure 11 presents the histogram obtained when the monitor and source stations use the D-Link-Athe- ros cards. Compared to Figure 5, in this case timestamping is done on the wireless card. The histogram is less precise with peaks spaced every 2 µs, which suggests that the clock resolution is of that order.

We thus conclude that to achieve the best precision, we need to use the monitor station with the Netgear-Prism GT card with timestamping done on the card.

TESTING WIRELESS EQUIPMENT

In this section, we illustrate the capacity of the proposed method to analyze different performance problems of wireless equipment. The emphasis is not on particular behavior of wireless cards, which was already reported in the literature, but what our method can do with its precision. In this part, we have used Dell Latitude D620 with Intel Core 2 duo processor at 2.00 GHz running Linux Fedora Core 6, 2.6.18.1 kernel with HZ=100 as the monitor station.

Tests of access points

We measure access points in an inverse configuration: the wired host generates traffic to a wireless station and the monitor station captures and timestamps packets. Recall that precise measuring of commercial access points cannot be done with existing methods, unless one can instrument the access point kernel.

The access points are the following:

• Linksys WRT 54GL (802.11g) under OpenWRT firmware,

• Asus WL-500G Premium (802.11g) under DD-WRT firmware,

• D-Link DWL 7100 (802.11a+g) with SuperG extensions of Atheros.

• Cisco Aironet 1132 AG (802.11a+g),

We fix the source rate to 30 Mb/s to minimize the effect of the saturation at the access point, because some access points perform badly if the arrival rate of packets exceeds the capacity of the wireless link (around 33 Mb/s at the transport level). If not stated otherwise, the receiving card is Intel Centrino-IPW3945 and the monitor uses the Netgear-Prism GT card with timestamping on the card. Figure 12 shows the results for Linksys WRT 54GL. We can see 16 regular peaks spaced at 143 µs with the first one at 595 µs. These surprising values are consistent with the measured throughput of 7 Mb/s and an AIFS of 2 slots, a slot being equal to 143 µs. This behavior of the card comes from the configuration variable of the access point called Wireless Distance, which by default is equal to 20 km. If this variable is set to 0, the slot becomes 9 µs and the throughput increases significantly. Figure 13 presents the histogram when this variable is set to 0. We can now see regular and narrow peaks with the first peak at 327 µs (only 1 µs difference from the standard value). The next tested access point is Asus WL-500G Premium with the histogram presented in Figure 14. The monitor card is Netgear-Prism GT with timestamping on the card. We can observe that the histogram is similar to that of Linksys WRT 54GL with the Wireless Distance variable set to 0-it is fairly regular with narrow peaks, the first one starting at 327 µs. As a side effect, these two experiments confirm the precision of measurements, because almost 90% of the values of each peak is contained in the central value. So, wider peaks denote either a variation of the timings on the sender side (when the same method is used) or a larger variation of the timestamping delay (when host timestamping is used).

Figure 15 presents the histogram for the D-Link DWL 7100 access point. The first peak is at 326 µs, which closely fits the standard. However, we can note a superposition of three histograms corresponding to different bit rates. Finally, we have analyzed the Cisco Aironet AP 1132 AG access point. Figure 16 shows its results: the peaks appear too early compared to the standard values by 4 µs, the first peak appearing at 322 µs. This behavior was surprising and lead us to a more detailed analysis. We have set up a measurement session to gather statistics on the behavior of the access point in contention with a test station. There is a downlink UDP flow from the Cisco access point to a second wireless station and the test station with the Intel Centrino-IPW2915 card sends an uplink flow to the wired host through the access point. In this set up, the access point is a sender and a receiver while the test station is only a sender. A third wireless station acts as a monitor to measure transmission times. Figure 17 presents the histogram of the transmissions done by the access point after its previous transmission (Cisco after Cisco) and a second one corresponding to the transmissions by the access point after a transmission by the test station (Cisco after Intel). Similarly, Figure 18 presents the histogram of the transmissions done by the test station after its previous transmission (Intel after Intel) and a second one corresponding to the transmissions of the test station after a transmission by the access point (Intel after Cisco). We can observe that the test station sends its frames independently of which entity sent the previous frame, but the access point sends its frames one slot earlier, if the previous transmission was done by the test station. The test station sends its frames more often after a transmission by the access point, so the contention is finally in favor of the test station: its throughput is 13.5 Mb/s vs. 13 Mb/s of the access point. Note also that the distribution of interarrival intervals has changed-it is no longer uniform, because the observed intervals have a complex distribution with a variable part, which is the minimum of a uniformly distributed random variable and the residual backoff time, resulting in a higher probability of short values.

Note that this comparison reports on the performance behavior of contending wireless stations-the measured transmission time includes the random backoff in the presence of two stations.

Tests of wireless cards

We have measured several wireless cards plugged into the source station in the standard configuration (cf. Figure 1). The access point is D-Link DWL 7100 and as previously, Dell Latitude D620 acts as a monitor. Figure 20 presents the histogram of the D-Link-Atheros card that supports SuperG extensions with Frame Bursting: it sends bursts of frames separated by the SIFS interval. We can see an important peak at 309 µs corresponding to the frames sent without contention (90% of frames) and a series of small peaks representing frames sent after a contention interval. We can compare this behavior with Figure 21 that shows a corresponding histogram without Frame Bursting. There are two superimposed histograms, the second one beginning at 367 µs represents frames sent at 48 Mbit/s. This comes from a rate control algorithm called Sample Rate-periodically, the card sends frames at a lower rate to determine the right rate to use [START_REF] Bicket | Bit-rate Selection in Wireless Networks[END_REF]. Such behavior probably shows an incorrect implementation of this algorithm, because in the conditions of the experimentation, the card should not switch to a lower rate, because it will not increase the throughput anyway. When we fix the bit rate, we obtain a much regular histogram (cf. Figure 22). The first peak is at 335.2 µs, which is 9 µs (1 slot) greater that the standard value. Finally, we have tested the Linksys-Broadcom wireless card under an experimental driver. We have observed that by default the card operates at 11 Mb/s (802.11b) and switches to 802.11g only if we fix the bit rate to 54 Mb/s. Figure 23 presents its histogram. We can see several anomalies:

• the first peak is at 350 µs instead of 326,

• the peaks are separated by 20 µs instead of 9 µs.

It appears that even if the card transmits at 54 Mb/s with the contention window of 16, it applies the time intervals corresponding to 802.11b (in particular the slot of 20 µs). Such timings are consistent with the throughput we have measured, which was around of 22 Mb/s instead of 29 Mb/s.

Discussion

We summarize here most common performance issues that we could identify with our method:

• Interframe intervals and backoff. Some cards do not respect the minimum interframe intervals (too early access to the channel) or use wrong values of the backoff slot. For almost all the wireless cards, the distribution of the backoff follows fairly closely the uniform distribution, but in the past, we have discovered some bugs in the implementation of the pseudorandom generator, e.g. one card generated 15 values instead of 16 with a double probability of the first value. Since then, the bug has been corrected.

• Bit rate adaptation. The method can detect multiple bit rates used by wireless cards. The algorithm for setting the bit rate in function of transmission conditions is not specified in the standard. So, the manufacturers can implement proprietary solutions such as Auto Rate Fallback [START_REF] Kamerman | WaveLAN-II: A High-Performance Wireless LAN for the Unlicensed Band[END_REF] or proposed improvements like Sample Rate [START_REF] Bicket | Bit-rate Selection in Wireless Networks[END_REF], but usually they perform poorly, because 802.11 does not distinguish between collisions and missed transmissions. This situation cannot improve unless the standard radically changes the access method to something that allows to set up the bit rate in a more optimal way such as in Idle Sense [START_REF] Heusse | Idle Sense: An Optimal Access Method for High Throughput and Fairness in Rate Diverse Wireless LANs[END_REF].

• Default configuration. Advanced equipment often provides a sophisticated management interface, but when the default configuration values do not correspond to the most common cases, users may face performance problems. Our example with the Wireless Distance variable shows that the default configuration may correspond to an unrealistic situation and the name of a configuration variable may be counter-intuitive for changing the duration of the backoff slot.

• Extensions of the standard. Our method can help evaluating extensions that some manufacturers support by anticipating the advances in standardization. We have shown how Frame Bursting can be identified and evaluated.

CONCLUSION

In this paper, we have proposed Interarrival Histograms, a method for measuring transmission delays in 802.11 wireless networks using commercially available equipment. The method is simple, yet powerfulit allows us to identify the temporal characteristics of tested cards and access points with high precision. We have derived the estimation of the measurement error and experimentally validated the method by applying it to the measurement of the 100 Mb/s Ethernet. To illustrate the cases in which the method can help analyzing the complex behavior of 802.11 networks, we have measured several commercially available access points and wireless cards to show some anomalies and differences with the standard.

By gathering sufficient number of interarrival interval samples and by using timestamping with 1 µs resolution, the precision of the method is sufficiently high for fine-grain measurements of 802.11 networks. At the first glance, such a precision is surprising, but our derivation of the error estimation provides the explanation-the influence of random delays incurred during timestamping and interrupt processing is canceled out when long series of interarrival intervals are measured.

Figure 1 :

 1 Figure 1: Measurement configuration.

SIFS

Figure 2 :

 2 Figure 2: Principle of measurements at the wired host.

2 Figure 3 :

 23 Figure 3: Principle of measurements at the monitor station.

Figure 4 :

 4 Figure 4: Histograms of transmission times for the 100 Mb/s Ethernet.

Figure 5 :Figure 6 :

 56 Figure 5: Histogram for the D-Link-Atheros card.

Figure 8 Figure 8 :

 88 Figure 8 presents histograms when three laptops with different processors act as monitors. They use

Figure 9 :

 9 Figure 9: Histograms in function of the interrupt frequency HZ.

Figure 10 :

 10 Figure 10: Timestamping by the Netgear-Prism GT card.

Figure 11 :

 11 Figure 11: Timestamping by the the D-Link-Atheros card.

Figure 12 :

 12 Figure 12: Linksys WRT 54Gl, default configuration.

Figure 13 :

 13 Figure 13: Linksys WRT 54GL, null variable of Wireless Distance

Figure 14 :

 14 Figure 14: Asus WL-500G Premium.

Figure 16 :

 16 Figure 15: D-Link DWL 7100.

Figure 17 :Figure 18 :

 1718 Figure 17: Histograms of the Cisco Aironet AP 1132 AG contending with the Intel Centrino-IPW2915 card.

Figure 19 :Figure 20

 1920 Figure 19: Histogram of Intel Centrino-IPW3945 measured with the D-Link access point. The first card is the Intel Centrino-IPW3945. Figure 19 presents its histogram when it uses the D-Link DWL 7100 AP. It is perfectly regular with the first

Figure 21

 21 Figure 21: D-Link card, regular mode.

Figure 23 :

 23 Figure 22: D-Link card, fixed bit rate of 54 Mb/s.

Table 1 :

 1 Transmission time statistics for the Ethernet in function of the frame size.

	Frame size [ bytes ]	200	400	600	800	1000	1200	1400
	Computed transmission time [µs] (Eq. 25)	21.280	37.280	53.280	69.280	85.280	101.280	117.280
	Histogram peak position [µs]	21	37	53	69	85	101	117
	Mean measured transmission time ( X) [µs]	21.280	37.280	53.280	69.280	85.280	101.280	117.280
	Difference average/computed [µs]	0.000	0.000	0.000	0.000	0.000	0.000	0.000
	Estimated standard deviation ( S)	0.007	0.007	0.013	0.011	0.013	0.012	0.012
	Error estimation ( , Eq. 24)	0.001	0.001	0.001	0.001	0.001	0.001	0.001

Table 2 :

 2 Influence of HZ.

	HZ	1000	250	100
	% Histogram	92.2	96.50	96.50
	1st peak	344.4	344.4	344.3
	difference	1.62	1.25	1.17

DIFS backoff

cf. Eq. 7 in which we drop the mark 3 in variable δ for simplicity.

DATA ACK ACK DATA DATA ACK ACK SIFS δ 1 3 DATA ACK ACK SIFS


Paritosh Sharma
email: paritosh.sharma@lisn.upsaclay.fr

A Layered Approach to Constrain Signing Avatars

RESEARCH PROBLEM

In human communication, the sign languages are the main languages used by deaf people around the world. Synthesis of these sign languages is a promising method for deaf communication, allowing us to customize and create new sign language content and preserve the artist's anonymity.

Triggering pre-recorded animations from a glossbased database is a common method for synthesizing sign language [START_REF] Pezeshkpour | Development of a legible deaf-signing virtual human[END_REF]. Here, a gloss represents the sign and is mapped to a clip of an avatar performing the sign. However, this technique requires a lot of time and manpower to create these pre-recorded clips. Therefore this method does not scale up well with large sign language utterances and cannot be applied to avatars in virtual worlds where maintaining large databases of animations is not possible.

These problems of scaling and data management have motivated research into the synthesis of sign language with procedural methods [START_REF] Gibet | High-level specification and animation of communicative gestures[END_REF]. Here, a gloss is mapped to a sequence of motion constraints to be evaluated and synthesized on the avatar. Nonetheless, synthesizing realistic motion with such systems remains a difficult problem, and addressing the signer's prosody, expressivity, and identity by providing control over style is even more challenging.

Glosses have traditionally been used as a formalization of sign language utterances. Yet this imposes the problem of synchronisation and reusability of those signs, which vary with a change in context.

To solve this, the AZee model [START_REF] Filhol | Nonmanual features: the right to indifference[END_REF]) allows us to write parameterised signed forms for semantic functions. Given a description, it generates a timeline that specifies every aspect of the utterance that the avatar should produce, resolving the problems with timing, sign concurrency, and non-manual features synchronization. Additionally, interpolation information is contained in AZee's temporal specifications, which is crucial for synthesizing the utterance.

This has motivated research for data-driven synthesis from AZee [START_REF] Filhol | Synthesizing Sign Language by connecting linguistically structured descriptions to a multi-track animation system[END_REF]. A synthea https://orcid.org/0000-0001-9938-008X sized utterance can be depicted as a set of blocks on a muti-track timeline [START_REF] Sharma | Multi-Track Bottom-Up Synthesis from Non-Flattened AZee Scores[END_REF]. These blocks can be generated using evaluated low-level posture constraints or pre-recorded animations. However, all low-level constraints were generalized as a set of Inverse Kinematics(IK) Problems to solve. For specific scenarios, relying on the IK and joint limits to constrain movement of the posture is not enough. Thus, we introduce a layer-based approach to solving constraints and show how it can be used for a complete data-driven sign language synthesis model.

OUTLINE OF OBJECTIVES

The objectives of this work can be summarized as follows:

• Show problems with only IK-based constraining.

• Present a new layered-based approach to better synthesize AZee constraints.

STATE OF THE ART

Animation from AZee descriptions can be divided into two categories: pre-animated and bottom-up synthesis(building from minimal constraints). Preanimated methods use explicit, often manually created, mappings of utterance description to motion data. [START_REF] Filhol | Extending the AZee-Paula shortcuts to enable natural proform synthesis[END_REF]) also uses template utterance descriptions and facilitates the generation of utterances with parameterized motion sequences. However, the diversity of these generated utterances is limited to the number of designed animations and database content. Moreover, the required manual labour hinders scalability. The Bottom-Up synthesis creates motion from minimalist constraints rather than relying on preanimated mappings. Despite recent research efforts, the naturalness of generated motion still falls significantly behind that of a pre-animated motion. However, it provides a broader coverage since it doesn't The above AZee expression is a representation of an SL production assigning "Iraq" to a point on the right-hand side of the signing space, a way of creating a reference the signer can later point to refer to the country. Let's assume we have pre-recorded action for the rule :Irak. fig. 1 represents this utterance on a multi-track timeline. The blocks constrain the posture in the following ways:

• HANDS CONTACT START.CAT.SIG: Placement constraints to keep the fingertips in contact in the beginning.

• HANDS CONTACT END.CAT.SIG: Placement constraints to keep the fingertips in contact at the end.

• TRANSPATH BLOCK.CAT.SIG: Transpath constraint specifying the movement of hands along an arc

• HAND CONFIG.CAT.SIG: Constraints for finger configuration.

• CHIN.SIG: Constrain the chin up

• GAZE: Constrain the gaze to the right signing space

• BODYLEAN: Orient the back so it leans towards the right.

• CHIN.SIG: Constrain the chin up

• FOCUS.SIG: pre-recorded action for the rule :Irak During block application, the IK chain to be chosen is based on the joint dependencies to evaluate the placement constraints. Though this system does allow for the extension of the IK chain through the spine, it invokes the solver with a new chain every time it applies a placement. This results in a slower evaluation of placements; moreover, the arms and torso have different purposes in the human body (fig. 2). The torso movement could have its own meaning irrespective of the movement of the arm. Lastly, whenever we switch the chain for the next constraint, we lose the IK information required by the other constraints, such as transpaths(movement specified along a path) or other placements.

To fix this, some systems define the spine, and arm IK separately [START_REF] Baerlocher | An inverse kinematic architecture enforcing an arbitrary number of strict priority levels[END_REF] [START_REF] Elliott | Linguistic modelling and languageprocessing technologies for avatar-based sign language presentation[END_REF]. [START_REF] Mcdonald | An automated technique for realtime production of lifelike animations of american sign language[END_REF] present the use of spine and shoulder extensions with an analytical hand IK model to address the timing of spine and shoulder movement separately. This allows for more natural bust movement. Avatar layers based on behaviour, skeleton and muscles were initially introduced by [START_REF] Chadwick | Layered construction for deformable animated characters[END_REF]. This interests us since we aim to define our posture based on its behaviour w.r.t. linguistic constraints. Thus, in the following section, we propose a layer-based posture configuration to solve and apply the native AZee constraints.

METHODOLOGY

The goal of our method is to constrain our posture using layers and specify the relationship between the layers through the native AZee constraints. [START_REF] Chadwick | Layered construction for deformable animated characters[END_REF]) define a layer as a conceptual simulation model which maps higher-level parametric input into lower-level outputs. Thus, using layers of the character related through the AZee constraints, we aim to add higher-level control over the low-level skeleton specification.

We define our posture using the following three behaviour layers:

IK Behaviour layer

The IK behaviour layer represents the motion specifications for the skeleton's arms and fingers. Having pre-defined chains in a layer also allows for better evaluation of transpath constraints. This layer encapsulates the chain movements for each arm bone and finger phalanges. When the IK is applied, a numerical IK solver generates the joint rotations for each bone in the chain. The mesh deformations are generated by weight painting [START_REF] Mohr | Direct manipulation of interactive character skins[END_REF] based on a given skeletal state.

Forward Kinematics(FK) Behaviour layer

The FK behaviour layer constitutes the motion specifications for all FK bones. It is used for all the local or global bone rotation changes in the skeleton. The constraints orient, rotate, trill, look and lookat use the FK layer.

Morph Behaviour layer

Certain linguistic constraints are more suitable to be evaluated using pre-defined shape keys rather than as other constraints in the IK or FK behaviour layers. For example, the following AZee expression constrains the posture to close its little finger.

L_closed azop 'param$0 'nodefault orient 'dir !little ˆparam$0 2 'along oppvect dir !palm ˆparam$0
However, this method is slower since it generates vectors for constraining each of the joints in the finger. When used for each finger, a rule like fist closed will generate 20 vectors for each joint. Thus, morphs make it more suitable to define a part of the sign language motion space. The following conditions can be considered when defining morphs,

• The morph action has a linguistic meaning(fist closed, brow raised, etc.)

• The morph action evaluates to local rotations on the skeleton or to some shape of the mesh independent of the skeleton layer.

Thus, the above expression can be rewritten as, A set of morphs is pre-defined on the morph layer and then applied to the posture with the specified weight during block evaluation.

Ordering the constraints

Once the Score is generated, for each block, the constraints have to be sorted based on their dependencies which can be represented as a dependency graph. The topological sorting of this graph gives us a set of sorted constraints. These sorted constraints are then used to create the dependency graph of the blocks, which determines the order of block evaluation. fig. 6 shows us the blocks for fig. 1 with their first constraint and edges representing dependencies.

Updating the layers

Since each layer affects the low-level skeleton specification, the other layers have to be updated with the skeleton as well during the constraint application.

IMPLEMENTATION

Pre-animated Dataset and Data Preparation

Based on our defined behaviour layers, we created simple animations for rules such as :Irak, :cuisine, etcetera. To use this action dataset effectively, we map the varying behaviour layer control node to the parameters from the AZee expression. fig. 7 shows the rule :Irak while the body leans towards right signing space.

Blender add-on

We implement our animator as an add-on in Blender(v3.4) [START_REF] Community | Blender -a 3D modelling and rendering package[END_REF]. fig. 8 shows the Blender interface configured with the AZee animator addon. Its main components include:

(a) Properties Modify inverse kinematics (IK) settings and animation layers.

(b) Viewport Shows the 3D scene with the avatar.

(c) Non-linear Editor

To place all the baked blocks from the utterance.

(d) Action Editor

The third etc allows us to modify and visualize the generated actions as well as the pre-recorded animations.

(e) AZee editor An editor to evaluate AZee expressions. It also includes settings for armature configuration, toggling constraints, managing body sites and defining global signing space and camera position.

We use the AutoRigPro [START_REF] Artell | Auto-rig pro[END_REF] add-on to implement the posture layers since it has pre-defined IK and FK switching mechanisms important for updating our layers.

EXPECTED OUTCOME

Our implementation is still under development. However, the current implementation allows us to visualise the AZee block timeline and generate simple utterances using both pre-recorded animations and minimal constraints. Synthesis for the utterance in fig. 1 can be seen at the following link.

https://github.com/Paritosh97/phd/raw/master/ grapp-2023/outcome.mp4

We see that the animator can synthesise AZee expressions using both bottom-up and pre-animated techniques.

STAGE OF THE RESEARCH

The theme of my PhD is the development of a synthesis system which can synthesize AZee descriptions of a sign language discourse through a descending order of granularity. As explained earlier, we use preanimated and bottom-up constraint synthesis for utterance generation. Thus, we can summarize the future goals of the PhD as follows.

• Improve usage of the pre-animated actions by parameterizing the motion data for the relevant specification given in the AZee expression.

• Increasing the quality of our bottom-up synthesis by increasing its naturalness using noise functions and better management of the f-curves using Bézier handles [START_REF] Bechmann | Animating with the "multidimensional deformation tool[END_REF].

• Integrating the above two techniques since the blocks generated using the bottom-up synthesis would look more robotic than those that used a pre-animated action. Here, applying the motion manifold from the pre-animated action data to solve the posture constraints can be a path to consider for a more seamless utterance generation [START_REF] Holden | Fast neural style transfer for motion data[END_REF].

• Testing and debugging our blender implementation for more complex utterances.

Figure 1 :

 1 Figure 1: Arrangement of the utterance for expression in section 3 on the timeline

Figure 2 :

 2 Figure 2: Hand IK chain pulling the spine and the shoulder

  Figure 3: Use of IK behaviour in HANDS CONTACT START.CAT.SIG block from fig. 1

Figure 4 :

 4 Figure 4: Use of FK behaviour in CHIN.SIG block from fig. 1

Figure 5 :

 5 Figure 5: Evaluated morph for little closed(w) = 0.5 L_closed azop 'param$0 'nodefault morph 'little_closed ˆparam$0 1.0

Figure 6 :

 6 Figure 6: Block DAG for expression in section 3

ACKNOWLEDGEMENTS

This work has been funded by the Bpifrance investment "Structuring Projects for Competitiveness" (PSPC), as part of the Serveur Gestuel project. Special thanks to my PhD director, Dr Michael Filhol, for providing guidance and feedback throughout this research.