---
title: "Creates a new session"
method: POST
path: "/qod/v0/sessions"
tags: ["Quality-of-Service on Demand v0.10.1"]
---

# Creates a new session

`POST /qod/v0/sessions`

Create QoS Session to manage latency/throughput priorities

If the qosStatus in the API response is "AVAILABLE" and a notification callback is provided the client will receive in addition to the response a
`QOS_STATUS_CHANGED` event notification with `qosStatus` as `AVAILABLE`.

If the `qosStatus` in the API response is `REQUESTED`, the client will receive either
- a `QOS_STATUS_CHANGED` event notification with `qosStatus` as `AVAILABLE` after the network notifies that it has created the requested session, or
- a `QOS_STATUS_CHANGED` event notification with `qosStatus` as `UNAVAILABLE` and `statusInfo` as `NETWORK_TERMINATED` after the network notifies that it has failed to provide the requested session.

A `QOS_STATUS_CHANGED` event notification with `qosStatus` as `UNAVAILABLE` will also be send if the network terminates the session before the requested duration expired

NOTE: in case of a `QOS_STATUS_CHANGED` event with `qosStatus` as `UNAVAILABLE` and `statusInfo` as `NETWORK_TERMINATED` the resources of the QoS session
are not directly released, but will get deleted automatically at earliest 360 seconds after the event.
This behavior allows clients which are not receiving notification events but are polling to get the session information with
the `qosStatus` `UNAVAILABLE` (the `statusInfo` parameter is not included in the current version but will be adding to `SessionInfo` in an upcoming release). Before a client can attempt to create a new QoD session
for the same device and flow period they must release the session resources with an explicit `delete` operation if not yet automatically deleted.

## Headers

- `x-rapidapi-host` string, required

## Request body

- object — Common attributes of a QoD session
  - `device` object, required — End-user equipment able to connect to a mobile network. Examples of devices include smartphones or IoT sensors/actuators. The developer can choose to provide the below specified device identifiers: * `ipv4Address` * `ipv6Address` * `phoneNumber` * `networkAccessIdentifier` NOTE: the MNO might support only a subset of these options. The API invoker can provide multiple identifiers to be compatible across different MNOs. In this case the identifiers MUST belong to the same device
    - `phoneNumber` string — A public identifier addressing a telephone subscription. In mobile networks it corresponds to the MSISDN (Mobile Station International Subscriber Directory Number). In order to be globally unique it has to be formatted in international format, according to E.164 standard, optionally prefixed with '+'.
    - `networkAccessIdentifier` string — A public identifier addressing a subscription in a mobile network. In 3GPP terminology, it corresponds to the GPSI formatted with the External Identifier ({Local Identifier}@{Domain Identifier}). Unlike the telephone number, the network access identifier is not subjected to portability ruling in force, and is individually managed by each operator.
    - `ipv4Address` union — The device should be identified by either the public (observed) IP address and port as seen by the application server, or the private (local) and any public (observed) IP addresses in use by the device (this information can be obtained by various means, for example from some DNS servers). If the allocated and observed IP addresses are the same (i.e. NAT is not in use) then the same address should be specified for both publicAddress and privateAddress. If NAT64 is in use, the device should be identified by its publicAddress and publicPort, or separately by its allocated IPv6 address (field ipv6Address of the Device object) In all cases, publicAddress must be specified, along with at least one of either privateAddress or publicPort, dependent upon which is known. In general, mobile devices cannot be identified by their public IPv4 address alone.
      - object
        - `publicAddress` string, ipv4, required — A single IPv4 address with no subnet mask
        - `privateAddress` string, ipv4, required — A single IPv4 address with no subnet mask
        - `publicPort` integer — TCP or UDP port number
      - object
        - `publicAddress` string, ipv4, required — A single IPv4 address with no subnet mask
        - `privateAddress` string, ipv4 — A single IPv4 address with no subnet mask
        - `publicPort` integer, required — TCP or UDP port number
    - `ipv6Address` string, ipv6 — The device should be identified by the observed IPv6 address, or by any single IPv6 address from within the subnet allocated to the device (e.g. adding ::0 to the /64 prefix). The session shall apply to all IP flows between the device subnet and the specified application server, unless further restricted by the optional parameters devicePorts or applicationServerPorts.
  - `applicationServer` object, required — A server hosting backend applications to deliver some business logic to clients. The developer can choose to provide the below specified device identifiers: * `ipv4Address` * `ipv6Address`
    - `ipv4Address` string — IPv4 address may be specified in form <address/mask> as: - address - an IPv4 number in dotted-quad form 1.2.3.4. Only this exact IP number will match the flow control rule. - address/mask - an IP number as above with a mask width of the form 1.2.3.4/24. In this case, all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version.
    - `ipv6Address` string — IPv6 address may be specified in form <address/mask> as: - address - The /128 subnet is optional for single addresses: - 2001:db8:85a3:8d3:1319:8a2e:370:7344 - 2001:db8:85a3:8d3:1319:8a2e:370:7344/128 - address/mask - an IP v6 number with a mask: - 2001:db8:85a3:8d3::0/64 - 2001:db8:85a3:8d3::/64
  - `devicePorts` object — The ports used locally by the device for flows to which the requested QoS profile should apply. If omitted, then the qosProfile will apply to all flows between the device and the specified application server address and ports
    - `ranges` object[]
      - `from` integer, required — TCP or UDP port number
      - `to` integer, required — TCP or UDP port number
    - `ports` integer[]
  - `applicationServerPorts` object — A list of single ports or port ranges on the application server
    - `ranges` object[]
      - `from` integer, required — TCP or UDP port number
      - `to` integer, required — TCP or UDP port number
    - `ports` integer[]
  - `qosProfile` string, string, required — A unique name for identifying a specific QoS profile. This may follow different formats depending on the service providers implementation. Some options addresses: - A UUID style string - Support for predefined profiles QOS_S, QOS_M, QOS_L, and QOS_E - A searchable descriptive name
  - `webhook` object
    - `notificationUrl` string, uri, required — Allows asynchronous delivery of session related events
    - `notificationAuthToken` string — Authentication token for callback API
  - `duration` integer — Session duration in seconds. Maximal value of 24 hours is used if not set. After session is expired the, client will receive a `QOS_STATUS_CHANGED` event with - `qosStatus` as `UNAVAILABLE`, and, - `statusInfo` as `DURATION_EXPIRED`. See notification callback.

## Response `201`

- object — Common attributes of a QoD session
  - `device` object, required — End-user equipment able to connect to a mobile network. Examples of devices include smartphones or IoT sensors/actuators. The developer can choose to provide the below specified device identifiers: * `ipv4Address` * `ipv6Address` * `phoneNumber` * `networkAccessIdentifier` NOTE: the MNO might support only a subset of these options. The API invoker can provide multiple identifiers to be compatible across different MNOs. In this case the identifiers MUST belong to the same device
    - `phoneNumber` string — A public identifier addressing a telephone subscription. In mobile networks it corresponds to the MSISDN (Mobile Station International Subscriber Directory Number). In order to be globally unique it has to be formatted in international format, according to E.164 standard, optionally prefixed with '+'.
    - `networkAccessIdentifier` string — A public identifier addressing a subscription in a mobile network. In 3GPP terminology, it corresponds to the GPSI formatted with the External Identifier ({Local Identifier}@{Domain Identifier}). Unlike the telephone number, the network access identifier is not subjected to portability ruling in force, and is individually managed by each operator.
    - `ipv4Address` union — The device should be identified by either the public (observed) IP address and port as seen by the application server, or the private (local) and any public (observed) IP addresses in use by the device (this information can be obtained by various means, for example from some DNS servers). If the allocated and observed IP addresses are the same (i.e. NAT is not in use) then the same address should be specified for both publicAddress and privateAddress. If NAT64 is in use, the device should be identified by its publicAddress and publicPort, or separately by its allocated IPv6 address (field ipv6Address of the Device object) In all cases, publicAddress must be specified, along with at least one of either privateAddress or publicPort, dependent upon which is known. In general, mobile devices cannot be identified by their public IPv4 address alone.
      - object
        - `publicAddress` string, ipv4, required — A single IPv4 address with no subnet mask
        - `privateAddress` string, ipv4, required — A single IPv4 address with no subnet mask
        - `publicPort` integer — TCP or UDP port number
      - object
        - `publicAddress` string, ipv4, required — A single IPv4 address with no subnet mask
        - `privateAddress` string, ipv4 — A single IPv4 address with no subnet mask
        - `publicPort` integer, required — TCP or UDP port number
    - `ipv6Address` string, ipv6 — The device should be identified by the observed IPv6 address, or by any single IPv6 address from within the subnet allocated to the device (e.g. adding ::0 to the /64 prefix). The session shall apply to all IP flows between the device subnet and the specified application server, unless further restricted by the optional parameters devicePorts or applicationServerPorts.
  - `applicationServer` object, required — A server hosting backend applications to deliver some business logic to clients. The developer can choose to provide the below specified device identifiers: * `ipv4Address` * `ipv6Address`
    - `ipv4Address` string — IPv4 address may be specified in form <address/mask> as: - address - an IPv4 number in dotted-quad form 1.2.3.4. Only this exact IP number will match the flow control rule. - address/mask - an IP number as above with a mask width of the form 1.2.3.4/24. In this case, all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version.
    - `ipv6Address` string — IPv6 address may be specified in form <address/mask> as: - address - The /128 subnet is optional for single addresses: - 2001:db8:85a3:8d3:1319:8a2e:370:7344 - 2001:db8:85a3:8d3:1319:8a2e:370:7344/128 - address/mask - an IP v6 number with a mask: - 2001:db8:85a3:8d3::0/64 - 2001:db8:85a3:8d3::/64
  - `devicePorts` object — The ports used locally by the device for flows to which the requested QoS profile should apply. If omitted, then the qosProfile will apply to all flows between the device and the specified application server address and ports
    - `ranges` object[]
      - `from` integer, required — TCP or UDP port number
      - `to` integer, required — TCP or UDP port number
    - `ports` integer[]
  - `applicationServerPorts` object — A list of single ports or port ranges on the application server
    - `ranges` object[]
      - `from` integer, required — TCP or UDP port number
      - `to` integer, required — TCP or UDP port number
    - `ports` integer[]
  - `qosProfile` string, string, required — A unique name for identifying a specific QoS profile. This may follow different formats depending on the service providers implementation. Some options addresses: - A UUID style string - Support for predefined profiles QOS_S, QOS_M, QOS_L, and QOS_E - A searchable descriptive name
  - `webhook` object
    - `notificationUrl` string, uri, required — Allows asynchronous delivery of session related events
    - `notificationAuthToken` string — Authentication token for callback API
  - `sessionId` string, uuid, required — Session ID in UUID format
  - `duration` integer, required
  - `startedAt` integer, required — Timestamp of session start in seconds since Unix epoch
  - `expiresAt` integer, required — Timestamp of session expiration if the session was not deleted, in seconds since Unix epoch
  - `qosStatus` 'REQUESTED' | 'AVAILABLE' | 'UNAVAILABLE', required — The current status of the requested QoS session. The status can be one of the following: * `REQUESTED` - QoS has been requested by creating a session * `AVAILABLE` - The requested QoS has been provided by the network * `UNAVAILABLE` - The requested QoS cannot be provided by the network due to some reason
  - `messages` object[]
    - `severity` 'INFO' | 'WARNING', required — Message severity
    - `description` string, required — Detailed message text

## Other responses

- `400`
- `401`
- `403`
- `409`
- `500`
- `501`
- `503`

---

[API](https://skmtc.dev/nokia/apis/network-as-code.md) · [All operations](https://skmtc.dev/nokia/apis/network-as-code/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/nokia/network-as-code/revisions/fdd5f5a56b88/schema)