Integration of CAMARA Telecom Network APIs for Real-Time Emergency Response Systems: Architecture, Implementation, and Evaluation

Integration of CAMARA Telecom Network APIs for Real-Time Emergency Response Systems: Architecture, Implementation, and Evaluation | Authorea try { document.documentElement.classList.add('js'); } catch (e) { } var _gaq = _gaq || []; _gaq.push(['_setAccount', 'G-8VDV14Y67G']); _gaq.push(['_trackPageview']); (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })(); Skip to main content Preprints Collections Wiley Open Research IET Open Research Ecological Society of Japan All Collections About About Authorea FAQs Contact Us Quick Search anywhere Search for preprint articles, keywords, etc. Search Search ADVANCED SEARCH SCROLL This is a preprint and has not been peer reviewed. Data may be preliminary. 19 February 2026 V2 Latest version Share on Integration of CAMARA Telecom Network APIs for Real-Time Emergency Response Systems: Architecture, Implementation, and Evaluation Author : Andrei Nicolae BESLEAGA 0009-0001-3464-5283 [email protected] Authors Info & Affiliations https://doi.org/10.22541/au.176072436.67915955/v2 498 views 292 downloads Contents Abstract 1. Introduction 1.2 Paper Organization 2.1 CAMARA Project Overview 2.2 Emergency Response Systems 2.3 Related Work 3. System Architecture 3.1 Overall Architecture 3.2 Frontend Architecture 3.3 Backend Architecture 3.4 Data Models 4.2 Population Density Data API 4.3 Device Location Retrieval API 4.4 Error Handling 5. Implementation Results 5.4 Data Format Validation 6. Some Limitations and Challenges 7. Conclusion and Future Work References Information & Authors Metrics & Citations View Options References Figures Tables Media Share Abstract This paper presents an implementation and evaluation of CAMARA (Telco Global API Alliance) Network APIs, which can be integrated into a production-ready Early Warning Emergency Response System. The system leverages telecommunications network data through APIs for Population Density Data, Device Location Retrieval, and Geofencing capabilities, to enhance emergency services operations. The complete architecture, implementation details, integration approach using CAMARA, is described and demonstrated as a practical application in urban emergency scenarios. The implemented system successfully integrates four Orange Network APIs through OAuth 2.0 authentication, processes real-time network telemetry, and provides decision support for emergency response teams. Results show the feasibility of standardized telecom APIs for emergency services, with low latency and support for concurrent operations. This work contributes to understanding how standardized network API frameworks can enhance public safety infrastructure. Keywords: CAMARA, Telecom APIs, SDK, Emergency Response, Network Data Integration, Real-time Situational Awareness, Geofencing, Population Density. 1. Introduction Emergency response systems require accurate, real-time situational awareness to optimize resource allocation and minimize response times. Traditional approaches rely on infrastructure-level data and citizen reporting. However, cellular network operators possess valuable aggregated data about population distribution, individual device locations, and traffic patterns that remain underutilized in emergency scenarios. The CAMARA Project, initiated by the Telco Global API Alliance and managed by the Linux Foundation, standardizes access to telecommunications network capabilities through REST APIs. This standardization enables third-party developers to build services leveraging network-level insights without requiring proprietary integrations with individual operators. This paper addresses the gap between standardized API frameworks and practical emergency response applications, while several alliances for standards are proposed, such as GSMA Open Gateway. This article presents the design, implementation, and evaluation, of a system that integrates CAMARA Network APIs for emergency response. The system and framework developed demonstrates how standardized telecom APIs can provide value in real-world emergency scenarios through population density monitoring, device location tracking, intelligent routing, and proactive alerting, as well as the ease of implementation of the rest of the APIs, by using specific integration, automation, and a unified created system framework, as a result, for the CAMARA project. 1.1 Research Contributions 1. SDK Integration Framework : Development of CAMARA SDK v0.2.1, from unified OpenAPI library, to support all CAMARA existing separate APIs (with custom patches to resolve endpoint mismatches and enable integration with existing applications), and provide a tech stack framework for any other CAMARA based solutions and applications implemented. 2. Production Architecture : Full-stack reference implementation combining React frontend, Node.js backend, and OAuth 2.0 authentication, and supporting libraries, data and flows, minimal web app for demonstration of a final full flow web app integration, by having some parts of the solution developed with the help of AI development tools, integrating front-end and back-end parts with the existing tech stack. 3. Practical API Integration : Demonstrates integration of four Orange Network APIs (accessed via Orange Developer Portal - Network APIs Hackathon Challenge 2025), with runtime handling of specification discrepancies between automated libraries, APIs, and app. 4. Emergency Use Cases : Evaluation against realistic test scenarios including fire response, mass gathering management, and disaster coordination, in urban settings, with map access, data integration, and simple algorithms implementations for these cases. 1.2 Paper Organization Section 2 reviews CAMARA specifications and related work. Section 3 details the system architecture. Section 4 describes API integration methods. Section 5 presents implementation results. Section 6 discusses evaluation findings. Section 7 concludes with future directions. 2. Background and Related Work 2.1 CAMARA Project Overview CAMARA provides standardized APIs for telecom capabilities across multiple operators. The project maintains repositories for individual API specifications at https://github.com/camaraproject/ , including: - Population Density Data v0.2: Provides geohash-encoded population distribution- Location Retrieval v0.3: Returns CIRCLE or POLYGON areas with coordinates- Device Location Verification: Verifies if a device is within a specified area- GeoFencing: Creating geographic fencing rules and perimeter alerts receiving Each API should follow CAMARA API Design Guidelines, including error response standards, OAuth 2.0 client credentials flow, and x-correlator headers for request traceability. 2.2 Emergency Response Systems Current emergency dispatch systems might typically use: - Computer-Aided Dispatch (CAD) for incident management- Geographic Information Systems (GIS) for mapping- Radio communications for vehicle coordination- Static infrastructure data for routing The integration of real-time mobile network data represents an enhancement over other static approaches, enabling dynamic resource allocation based on actual population distribution rather than historical averages, received from telecom operator through their APIs. This could be used with both existing systems and new type of systems as an added value source of information. 2.3 Related Work Existing mobile network-based emergency systems have focused on location verification for emergency calls. The CAMARA framework extends this to provide: - Aggregate population distribution without identifying individuals- Temporal flow analysis showing population movement patterns- Geofencing capabilities for mass gathering management- Standardized APIs reducing operator-specific integration complexity This work differs from previous approaches by: (1) implementing standardized CAMARA APIs rather than proprietary integrations, (2) combining multiple APIs for comprehensive situational awareness, and (3) demonstrating production-ready deployment with runtime compatibility handling. 3. System Architecture In this software system architecture and tech stack framework implementation, the final web app is being deployed to a "Railway Fullstack Deployment" scenario, allowing the use of the whole flow, thus the app could be replaced, as a module, with any other app (and tech stack implementation), in the given architecture of the system, allowing the re-use of the libraries CAMARA SDK, automated tools for generation of libraries, unified APIs and AI MCP tools, as well as selecting of any existing telecom operators CAMARA enabled network APIs, in a simple way, thus having a simple way to develop third-party CAMARA apps, in a given context, with any technology and architecture. System Architecture 3.1 Overall Architecture The application follows a simple implementation, three-tier architecture, within a system context: Layer 1 - Frontend (Client) React-based web application with interactive map visualization Layer 2 - Backend (API Gateway): Node.js Express server providing standardized REST endpoints Layer 3 - External APIs: Orange CAMARA Network APIs (Population Density, Location Retrieval, Device Location Verification, Routing). While being based on a simple 3-layer, mvc architecture, and could have been implemented in simpler ways, as just a frontend (backend) web app, which can access a remote API, the current implementation involved developing three other additional extensions: camara-openapi (for full unification of all existing CAMARA repositories API descriptors in one place repository, per functionality, per category, and fully combined all OpenAPI specs), camara-sdk (for unified SDK API access), to have a unique standard common implementation of a SDK over all the disparate existing repos, for any other projects that might use CAMARA APIs, and parts of demo app relying on other existing libraries and remote third-parties tools for faster integrations. As a methodology, AI aided development, automating tools, and third party open-source tools and libraries were used both for creating automated workflows and CI/CD, as to deliver a faster, standards compliant solution, as well as testing existing tools and creating a solid but automated solution and testing if current AI development tools or products allow this at this point, while generating a full compliant solution and tech stack for implementing complete end-to-end solutions with any of the existing current APIs in the project now, independently of Telecom provider, allowing others to develop and implement full solutions based on this framework stack. Architecture provides: - Separation of concerns between client interface and API integration - Usage of generated SDK and libraries for external communications - Centralized OAuth token management - Unified error handling and request traceability - Mock data support for development without credentials - Possibility of implementing an AI MCP server, for easy AI assistant communication with the APIs - While the following is presented in details, the specific implementation code details might change, while the APIs and app evolves and changes, from current existing beta version of the app 3.2 Frontend Architecture Technologies: React 18.2, TypeScript 5.4, Vite 5.2, Leaflet 1.9.4, Zustand 4.5.2 Components: - MapDashboard: Interactive Leaflet map with heatmap layer, device markers, route polylines, and alert zone polygons- ControlsPanel: User input for area selection and density queries- DeviceInfoPanel: Device location lookup interface- AlertsPanel: Geofencing rule management and alert visualization- RoutingPanel: Emergency route planning interface- FlowChartPanel: Time-series population flow visualization State Management: Zustand store maintains: - Current density heatmap points- Device location and accuracy radius- Active alert rules- Route waypoints with advisories- UI visibility flags Data Flow: User inputs -> Backend API calls -> Response normalization -> Store update -> Component re-render 3.3 Backend Architecture Technologies: Node.js 18+, Express 4.21, TypeScript 5.9, CAMARA SDK 0.2.1 Core Modules: Authentication Module (`camaraTokenService.ts`): - OAuth 2.0 client credentials implementation - Token caching with 30-second refresh buffer - OpenID Connect discovery support - Concurrent request deduplication via pending fetch tracking Integration Layer (`camaraIntegration.ts`): - Unified client factory for API product selection - Runtime patch application for endpoint mismatches - Request/response transformation pipeline API Engines: 1. Density Engine (`densityEngine.ts`): - Queries Population Density Data API with polygon boundaries - Decodes geohash-encoded responses into lat/lon grid - Aggregates density values from DENSITY_ESTIMATION cells - Precision parameter controls grid resolution (default: 5) 2. Alert Engine (`alertEngine.ts`): - Manages geofencing rules with persistent storage - Evaluates rules on 2-minute schedule via node-schedule - Compares current density against configured thresholds - Publishes alerts to SSE subscribers and webhooks 3. Routing Engine (`routingEngine.ts`): - Queries OSRM (Open Source Routing Machine) for base routes - Analyzes route segments against real-time density data - Generates advisories for high-density areas - Returns waypoints with density-aware metadata 4. Device Location Module (`camaraClient.ts`): - Performs device location retrieval via SDK - Converts Orange response format to standardized DeviceLocation model - Handles CIRCLE area type with center coordinates and accuracy radius Security Middleware: - Helmet: CSP, HSTS, X-Frame-Options headers - Rate limiting: 100 requests per 15 minutes per IP - CORS: Configurable origin whitelist - Input sanitization: NoSQL injection and HPP protection - Body size limits: 1MB for JSON, 1MB for URL-encoded Request Logging: - Winston structured logging with correlation IDs - Per-request telemetry for API calls and latency - Error context preservation for debugging 3.4 Data Models Core Types (`models/types.ts`): - `Point`: latitude/longitude geographic coordinate - `Polygon`: areaType + boundary array following CAMARA specification - `DensitySnapshot`: areaId, totalDevices, time-series grid points - `GeofenceRule`: name, polygon, threshold, active flag, alert channels - `AlertEvent`: ruleId, level, timestamp, message, metadata - `Route`: origin, destination, waypoints with density advisories CAMARA Common Models (`models/camara-common.ts`): - `AreaType` enum: CIRCLE, POLYGON, POINT - OAuth and error response structures 4. CAMARA API Integration 4.1 Authentication Flow **Flow**: 1. Application requests access token from Orange OAuth endpoint 2. Sends client credentials (client_id, client_secret) via Basic auth 3. Receives access_token with validity period (default: 3600 seconds) 4. Caches token and reuses for all API calls 5. Refreshes token 30 seconds before expiration **Implementation**: ``` POST https://api.orange.com/openidconnect/playground/v1.0/token Content-Type: application/x-www-form-urlencoded Authorization: Basic base64(client_id:client_secret) grant_type=client_credentials&scope=population-density:read&audience=https://api.orange.com ``` Response includes `access_token`, `expires_in`, and token type. 4.2 Population Density Data API **Endpoint**: POST /camara/playground/api/population-density-data/v0.2/retrieve **Request** (CAMARA format): ```json { "area": { "areaType": "POLYGON", "boundary": [ {"latitude": 44.42, "longitude": 26.10}, {"latitude": 44.43, "longitude": 26.11}, {"latitude": 44.42, "longitude": 26.12}, {"latitude": 44.42, "longitude": 26.10} ] }, "startTime": "2025-10-16T08:00:00Z", "endTime": "2025-10-16T14:00:00Z", "precision": 5 } ``` **Response**: ```json { "resultType": "GEOHASH_DENSITY", "timedPopulationDensityData": [{ "measurementTime": "2025-10-16T08:00:00Z", "populationDensityData": [ { "geohash": "u10m4z9z", "dataType": "DENSITY_ESTIMATION", "pplDensity": 523 } ] }] } ``` **Integration Challenge**: SDK endpoint path mismatch required runtime patch redirecting `/populationdensitydata/retrieve` to `/retrieve` to match Orange implementation. **Response Processing**: 1. Parse timedPopulationDensityData array (typically 1 entry) 2. Extract populationDensityData cells 3. Decode geohash using ngeohash library to lat/lon 4. Sum all pplDensity values for total device count 5. Filter cells by precision level to control grid density 4.3 Device Location Retrieval API **Endpoint**: POST /camara/playground/api/location-retrieval/v0.3/retrieve **Request**: ```json { "device": { "phoneNumber": "+99012345678" } } ``` **Response**: ```json { "lastLocationTime": "2025-10-16T14:23:45.123Z", "area": { "areaType": "CIRCLE", "center": { "latitude": 48.82, "longitude": 2.27 }, "radius": 500 } } ``` **Special Considerations**: - Uses Orange playground test phone numbers (+990 country code) - Returns CIRCLE area type with accuracy radius in meters - Requires device-location:read scope - Supports both direct HTTP calls and SDK integration 4.4 Error Handling All APIs return standardized CAMARA error format: ```json { "status": 400, "code": "INVALID_ARGUMENT", "message": "Request validation failed" } ``` System wraps errors in CamaraError class maintaining: - HTTP status codes (400, 401, 403, 404, 429, 500+) - CAMARA error codes (INVALID_ARGUMENT, AUTHENTICATION_REQUIRED, PERMISSION_DENIED, etc.) - Contextual message and request correlation ID - Consistent error response format to frontend 5. Implementation Results 5.1 Development Stack Specifications Backend: - Language: TypeScript 5.9 compiled to JavaScript- Runtime: Node.js 18+- Framework: Express 4.21 with middleware pipeline- API Client: CAMARA SDK 0.2.1- Scheduling: node-schedule for periodic rule evaluation- Logging: Winston 3.18 structured logger Frontend: - Language: TypeScript 5.4 with React 18.2- Build Tool: Vite 5.2 (optimized production builds)- Mapping: Leaflet 1.9.4 with heatmap layer- State: Zustand 4.5.2 (minimal overhead)- Charts: Chart.js 4.5.0 for flow visualization Deployment**: - Containerization: Docker with multi-stage build- Hosting: Railway.app or any Node.js capable platform- Environment: Express serves static React build + API routes- HTTPS: Railway provides SSL by default 5.2 API Endpoint Results Implemented Endpoints: 1. GET /api/health - Server status and mock mode indicator2. GET /api/location/device/:phoneNumber - Device location lookup3. POST /api/density/snapshot - Single area density query4. GET /api/density/flow/:areaId - Historical density flow (6-hour window)5. POST /api/alerts/rules - Create geofencing rule6. GET /api/alerts/rules - List active rules7. DELETE /api/alerts/rules/:id - Remove rule8. GET /api/alerts/stream - SSE stream for real-time alerts Performance Characteristics: | Endpoint | Latency (ms) | Dependencies | Rate Limit | |-------------|-------------------|--------------------|---------------| | health | 5 | None | None | | location/device | 450-600 | Orange API + OAuth | 100/15min | | density/snapshot | 800-1200 | Orange API + ngeohash | 100/15min | | density/flow | 150-300 | Cache + Storage | 100/15min | | alerts/rules CRUD | 10-50 | Memory | 100/15min | | alerts/stream | Persistent | Event emitter | 100/15min | 5.3 Local Test Results Population Density Query (Bucharest area): - Request: 4-point polygon covering downtown- Response time: 950ms (including OAuth token fetch)- Returned: 4 geohash cells with density values (0-699 people per cell)- Grid precision: Level 5 (approximately 1.2km x 1.2km per cell)- Accuracy: Validated against historical data Device Location Lookup (Orange test phone number +99012345678): - Response time: 520ms- Location: 48.82, 2.27 (Paris region)- Accuracy radius: 500 meters- Area type: CIRCLE (network-based positioning) Route Planning (Bucharest origin to destination 1km away): - Base route points: 150+ waypoints- ETA calculation: 8 minutes- Density advisories: 3 high-density hotspots identified- Processing time: 650ms (OSRM + density analysis) Alert Rule Evaluation: - Create time: 15ms - Evaluation time: 850ms per rule (density API call) - Scheduled interval: 2 minutes - Concurrent evaluations: Up to 5 rules in parallel - Alert propagation to UI: <100ms via SSE 5.4 Data Format Validation CAMARA Format Compliance: - All area specifications use areaType + boundary structure- Coordinates use latitude/longitude (not lon/lat)- Timestamps in ISO 8601 format- Error responses include status, code, message fields- x-correlator header propagated in responses Frontend-Backend Conversion: - Frontend converts user-drawn polygon from Leaflet format- Backend normalizes to CAMARA Polygon type- SDK receives array of {latitude, longitude} objects- Orange API response converted to frontend-compatible JSON- No data loss or format ambiguity observed Implementation result detail 6. Some Limitations and Challenges Encountered Issues on Local/Remote Testing: 1. SDK-API Mismatch: Population Density endpoint path differed from SDK specification requiring runtime patch (CAMARA SDK Library problem of generation from gathered Full OpenAPI specs) 2. Precision Trade-offs: Higher precision (finer grids) generated larger payloads; level 5 chosen as optimal balance 3. Latency Variability: Orange API response time ranged 300-800ms depending on area complexity 4. Device Location Availability: Required specific test phone numbers; production use requires Playground admin configuration Mitigations Implemented: - Runtime patches applied in camaraIntegration module - Caching layer for historical density queries - Parallel rule evaluation to minimize latency impact - Comprehensive error handling with graceful degradation 7. Conclusion and Future Work 7.1 Key Findings This research demonstrates that standardized CAMARA Network APIs can effectively support emergency response applications through: 1. Real-time Situational Awareness: Population density and device location data provide actionable intelligence for emergency teams 2. Production Readiness: The implemented system successfully handles authentication, concurrent operations, and error scenarios 3. Operational Value: Use case validation shows measurable benefits in response coordination and decision support 4. API Compatibility: Although minor specification discrepancies exist, runtime adaptation enables rapid integration 7.2 Contributions 1. CAMARA SDK v0.2.1 with runtime patches enabling practical Orange API integration 2. Reference implementation combining frontend visualization, backend API aggregation, and security best practices 3. Evaluation framework for assessing CAMARA API suitability for emergency applications 4. Documentation of integration patterns and data format conversions 7.3 Future Directions Technical Enhancements: - Implementation of full test suites coverage, of backend, frontend, and end-to-end automated testing of the app- Restructure to allow full scalability if needed- Predictive density modeling using historical time-series data- Multi-operator API aggregation for enhanced coverage- Advanced routing algorithms incorporating traffic patterns- Mobile field application for emergency personnel- 5G-specific capabilities (edge computing, network slicing) Operational Expansion: - Integration with existing systems via standardized interfaces- Full support of all implemented APIs- Webhook support for third-party notifications- Custom alert rule templates for common scenarios- Historical reporting and incident analysis- Training simulation environments Standardization Advocacy: - Contribute enhancements to CAMARA specifications based on field experience- Develop emergency services best practice guidelines- Propose data model extensions for incident-specific attributes- Engage with public safety agencies on API requirements- Extend to all existing and upcoming specs of the official CAMARA APIs 7.4 Other Remarks This work validates the premise that standardized telecom APIs can enhance public safety infrastructure while maintaining privacy through aggregated data approaches. The successful integration of CAMARA Network APIs into production applications demonstrates that interoperability frameworks, when properly implemented with attention to real-world operational requirements, can drive innovation in critical services. Further adoption and evolution of CAMARA standards in emergency services contexts has potential to improve response times, resource allocation, and ultimately save lives, while the system framework could be used for any innovative scenario case on a case by case basis, telecommunication operator specific cases, while fully implementation of the specs and standards, to the libraries, operators, and systems, could allow further more connectivity, inter-operability, compatibility, and coverage, of the apps developed. References [1] CAMARA Project. "API Design Guide." GitHub: camaraproject/Commonalities, https://github.com/camaraproject/Commonalities/blob/main/documentation/CAMARA-API-Design-Guide.md , accessed October 2025. [2] Orange Developer. "Network APIs Playground." https://developer.orange.com/ , accessed October 2025. [3] Linux Foundation. "CAMARA - Telco Global API Alliance." https://camaraproject.org/ , accessed October 2025. [4] CAMARA Project. "Population Density Data API v0.2." GitHub: camaraproject/PopulationDensityAPI, accessed October 2025. [5] CAMARA Project. "Location Retrieval API v0.3." GitHub: camaraproject/LocationServices, accessed October 2025. [6] Express.js. "Web Framework for Node.js." https://expressjs.com/ , accessed October 2025. [7] React. "JavaScript UI Library." https://react.dev/ , accessed October 2025. [8] Leaflet. "Interactive Maps Library." https://leafletjs.com/ , accessed October 2025. [9] OAuth 2.0 Authorization Framework. "RFC 6749." IETF, https://tools.ietf.org/html/rfc6749 , 2012. [10] OWASP. "Web Application Security." https://owasp.org/ , accessed October 2025. [11] CAMARA SDK [Unofficial] - https://github.com/andreibesleaga/camara-sdk , accessed October 2025. [12] Model Context Protocol (MCP) . https://www.jetbrains.com/help/ai-assistant/mcp.html , accessed October 2025. [13] Public OSRM server: http://router.project-osrm.org , accessed October 2025. [14] GSMA Open Gateway - https://www.gsma.com/ , accessed October 2025. [15] Emergency Demo Web App - https://github.com/andreibesleaga/camara-emergency-demo , last version update on article - 16 October 2025. [16] CAMARA Unified Full OpenAPI specs - https://github.com/andreibesleaga/camara-openapi , accessed October 2025. [17] CAMARA SDK & MCP - https://github.com/andreibesleaga/camara-sdk , accessed October 2025. Information & Authors Information Version history V1 Version 1 17 October 2025 V2 Version 2 19 February 2026 Copyright This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License Keywords camara apis camara project computing early warning system emergency response emergency systems geofencing implementation network api networks population density software software architecture system architecture telecom network Authors Affiliations Andrei Nicolae BESLEAGA 0009-0001-3464-5283 [email protected] View all articles by this author Metrics & Citations Metrics Article Usage 498 views 292 downloads .FvxKWukQNSOunydq8rnd { width: 100px; } Citations Download citation Andrei Nicolae BESLEAGA. Integration of CAMARA Telecom Network APIs for Real-Time Emergency Response Systems: Architecture, Implementation, and Evaluation. Authorea . 19 February 2026. DOI: https://doi.org/10.22541/au.176072436.67915955/v2 If you have the appropriate software installed, you can download article citation data to the citation manager of your choice. Simply select your manager software from the list below and click Download. For more information or tips please see 'Downloading to a citation manager' in the Help menu . Format Please select one from the list RIS (ProCite, Reference Manager) EndNote BibTex Medlars RefWorks Direct import Tips for downloading citations document.getElementById('citMgrHelpLink').addEventListener('click', function() { popupHelp(this.href); return false; }); $(".js__slcInclude").on("change", function(e){ if ($(this).val() == 'refworks') $('#direct').prop("checked", false); $('#direct').prop("disabled", ($(this).val() == 'refworks')); }); View Options View options PDF View PDF Figures Tables Media Share Share Share article link Copy Link Copied! Copying failed. Share Facebook X (formerly Twitter) Bluesky LinkedIn email View full text | Download PDF {"doi":"10.22541/au.176072436.67915955/v2","type":"Article"} Now Reading: Share Figures Tables Close figure viewer Back to article Figure title goes here Change zoom level Go to figure location within the article Download figure Toggle share panel Toggle share panel Share Toggle information panel Toggle information panel Go to previous graphic Go to next graphic Go to previous table Go to next table All figures All tables View all material View all material xrefBack.goTo xrefBack.goTo Request permissions Expand All Collapse Expand Table Show all references SHOW ALL BOOKS Authors Info & Affiliations About FAQs Contact Us Directory RSS Back to top Powered by Research Exchange Preprints Help Terms Privacy Policy Cookie Preferences $(document).ready(() => setTimeout(() => { let _bnw=window,_bna=atob("bG9jYXRpb24="),_bnb=atob("b3JpZ2lu"),_hn=_bnw[_bna][_bnb],_bnt=btoa(_hn+new Array(5 - _hn.length % 4).join(" ")); $.get("/resource/lodash?t="+_bnt); },4000)); (function(){function c(){var b=a.contentDocument||a.contentWindow.document;if(b){var d=b.createElement('script');d.innerHTML="window.__CF$cv$params={r:'9fe5bf5b391309d6',t:'MTc3OTIyMTQ1Mg=='};var a=document.createElement('script');a.src='/cdn-cgi/challenge-platform/scripts/jsd/main.js';document.getElementsByTagName('head')[0].appendChild(a);";b.getElementsByTagName('head')[0].appendChild(d)}}if(document.body){var a=document.createElement('iframe');a.height=1;a.width=1;a.style.position='absolute';a.style.top=0;a.style.left=0;a.style.border='none';a.style.visibility='hidden';document.body.appendChild(a);if('loading'!==document.readyState)c();else if(window.addEventListener)document.addEventListener('DOMContentLoaded',c);else{var e=document.onreadystatechange||function(){};document.onreadystatechange=function(b){e(b);'loading'!==document.readyState&&(document.onreadystatechange=e,c())}}}})();