dedicated-network-accesses.yaml missing device lifecycle

[sergiobrisio]

Problem description

lack of a lifecycle status for the dedicated network accesses (DN_A)

Expected behavior

add lifecycle in DN_A like: Pending, Active, Inactive, Suspended, Revoked, Failed, Decommissioned. It could be done adding in the yaml file a new component like the one managing network statu in dedicated-network.yaml file:

AccessNetworkStatus:
  description: |
    The current status of the access request for the dedicated network. The status can be one of the following:
    * `PENDING` - The access is requested, but not yet approved or provisioned. Possible Transitions: ACTIVE (if approved). FAILED (if the provisioning process encounters an error). REVOKED (if the request is explicitly denied).
    * `ACTIVE` - The access is fully approved and currently enabled. Possible Transitions: INACTIVE (manual or automated deactivation after inactivity). SUSPENDED (temporary suspension due to security or billing issues).    REVOKED (permanent withdrawal of access). DECOMMISSIONED (final retirement of access, often after a lifecycle end).
    * `INACTIVE` - The access is no longer actively used and is pending deletion. Possible Transitions: ACTIVE (reactivated if needed). DECOMMISSIONED (if truly obsolete and removed). REVOKED (if a decision is made to deny future access).
    * `SUSPENDED` - The access is temporarily disabled (e.g., for maintenance or security reasons) but not permanently revoked.  Possible Transitions: ACTIVE (restored if the issue is resolved). REVOKED (if an investigation concludes access should be withdrawn). DECOMMISSIONED (if the access is ultimately retired and cleaned up).
    * `REVOKED` - The access is permanently withdrawn; reactivation requires a new request.
    * `FAILED` - The provisioning or approval process encountered an error or was explicitly rejected. Possible Transitions:  PENDING (in some cases, if an automated retry is possible).
    * `DECOMMISSIONED` - The access has reached its end of life, with all related resources cleaned up.     Reactivation is not possible.

  type: string
  enum:
    - PENDING
    - ACTIVE
    - INACTIVE
    - SUSPENDED
    - REVOKED
    - FAILED
    - DECOMMISSIONED

Alternative solution

without a state in DN_A we have a device which could be in or out so only with a binary alternative. This could raise concerns related to security and operation, user experience...

Additional context

Example of concerns:

Potential security concerns:

1. unauthorized access:
   if a device is either “authorized” or “not,” there is limited granularity to manage security. For example, if a device should be blocked temporarily (e.g., suspected compromise, unusual behavior), security rules might force a permanent removal, losing any future ability to re-enable it securely. Allowing a “quarantine” approach may avoid this issue.
2. security loopholes:
   If a device that was “off” (when it should have been simply "revoked"), it could potentially be re-added, without passing thorough the correct process and related auditing (i.e. identifying correctly the reason for removal).
3. data protection:
   a device that was simply turned “off” might still hold sensitive data or keys, while a “decommissioned” or “expired” state, may trigger an automatic process to remove or rotate credentials, keys, or data backups…

Potential operational concerns:

1. Downtime & Availability: as for the network itself, an incomplete transaction may affect the service context for the device.
2. Overload & Inefficiency: if devices can be in inactive or suspended states when not in use, we may prevent unnecessary resource consumption
3. Scalability: a single binary state leads to repeated manual interventions and potential mistakes when the number of devices scales, automated transitions between states may streamline operation and reduce manual activities.
4. decommissioned hardware management: a dedicate status can handle the need to manage the end of support for a device.

User transparency:
When users or administrators see only two states, the “off” state by itself do not clarify why or what is needed to get it back “on”, but adding distinct states like pending, failed, expired provides transparent feedback about why a device is not active (making easier the troubleshooting) and the lifecycle can drive “how” it can be reactivated.

[tlohmar]

@sergiobrisio, thanks for raising the issue. I think, there are some different aspects to discuss:

1. Whether we should allow different states of the Access resource (Device access to a network). It may take some time until e.g. a device owner is ok to get access.
2. I would suggest to separate between states and state reasons. For example, the state of the access may be inactive, while the reason was revoked by the user, or temporarily suspended.

Note, whether the device is actually using the access to the network for establishing a connection is yet another question.

[sergiobrisio]

Hi @tlohmar thanks for the comment. For topic (1) I think that in the case of waiting time / thinking time the DN_A status lifecycle idea is to make use of the "PENDING" state, which would allow operation or security or billing policies to decide (active/inactive). For operation the flow is from an errored situation to -> PENDING and then one of the 2 (active/inactive).

For (2) you are suggesting reducing the number of states and adopt state reason to join this objective.
I agree and I would propose for example to reduce just to PENDING/ACTIVE/INACTIVE/DECOMMISSIONED (i.e. removing SUSPENDED, REVOKED and FAILED)

INACTIVE state would become broader, but the simplification we can get is great.

Your idea is to complete transition adding a state_reason
For the ACTIVE->INACTIVE those state_reason would add info like:
USER_REQUEST (the user manually turned it off)
REVOKED_BY_ADMIN (administrative or policy decision: this would avoid the REVOKED state)
SECURITY_ISSUE
BILLING_ISSUE

The reverse transition (INACTIVE -> ACTIVE) could be enriched by the state_reason of the resolution.
Let's imagine now to have a SIM that was revoked for security reasons: the previous lifecycle was not allowing a transition from REVOKED to ACTIVE, while with the simplified lifecycle with state_reason we need to add an external business logic to detect that for a specific state_reason like REVOKED_BY_ADMIN it would not be possible to have the transition INACTIVE -> ACTIVE...
I do not see it as an issue, unless we have an application which does not tolerate any kind of security risk to force us to stay with a distinct REVOKED status.

For the PENDING-> INACTIVE transition we could add simply
FAILED_PROVISIONING (something went wrong during setup): this would avoid the “FAILED” state

For the INACTIVE-> DECOMMISSIONED transition we could add simply
EXPIRED (time-based expiry, license ended, or contract ended): this would avoid the "SUSPENDED" state

---

I am now thinking to a concrete use case suggested me by Steve.

<<A Media Producer creates a Dedicated Network for 20th September from 9am-2pm in central London to cover the London Marathon. They have 10 cameras, each of which requires access at all times, as well as a mobile camera that will be used occasionally.>>

In this scenario <<what state are the camera’s in? are they pending (until 20th?) or Active?>>
Simplified: PENDING/ACTIVE/INACTIVE/DECOMMISSIONED
Considered that all the mechanisms have been tested:
The 10 Cameras should probably be progressively moved from PENDING to ACTIVE state just few minutes before the London marathon would pass near the specific Camera, in order to consume the available network quotas for the slice as late as possible.

The CSP could check if the available quotas for the specific slice are enough to get the additional camera inside the slice...
The additional mobile camera has probably to stay ACTIVE considering it acts as "spare" and should be life asap.

So for this case a PENDING status should be mandatory, not only for the @tlohmar consideration in (1) on provisioning time, but also to perform any kind of check on available quotas, or anytime a camera has to become (newly) ACTIVE, right?

Now in ACTIVE state, let's suppose that a security issue is happening, for example the additional camera has been hacked...
We want to remove from the slice, so in this simplified lifecycle we would move to INACTIVE state with "SECURITY_ISSUE" state_reason
The trigger point for the security team could simply be the state_reason and not the state itself, which brings to the point of adding business logic.
For example, in an implementation based on events, we will add state_reason inside the topic of the event broker...

<<Under what scenario would this state change? >>
The state change from ACTIVE to INACTIVE should handle the end of the marathon, so the laziest athletes could be the triggers to switch off the fixed cameras...
The state change from INACTIVE to PENDING should be avoided
The state change from INACTIVE to ACTIVE could raise again some security concern: what if the resolution reason is not correct or left unknown/not properly documented reason? I think this could open the door to hacking again...
The DECOMMISSIONED state should be used rarely, but when the devices have to change sw release it helps a lot to avoid spotting vulnerabilities in old sw / os / etc

<<Do the individual cameras need to know their state? >>
I think yes, because application logic would connect the operating state of the device with our network state. If the camera is broken or has been hacked, we need to avoid allocating quotas so the status transition to INACTIVE should be potentially stated by the camera or by a management master which known remotely the admin status of the camera or has detected a failure in a liveness probe etc...

[sergiobrisio]

AccessNetworkLifecycle:
type: object
description: |
Represents the lifecycle of a network access resource with a simplified state model.
The additional 'reason_code' field might capture the rationale
behind certain state changes.

**Reason Codes**:
- Used to provide additional context for why the resource is in a given state
  or why a transition occurred. For critical transitions (especially security-related),
  a reason_code SHOULD be provided.

properties:
status:
type: string
enum:
- PENDING
# Indicates the access has been requested but is not yet approved or provisioned.
- ACTIVE
# The access is fully approved and currently enabled.
- INACTIVE
# The access is not actively used. Typically, resources are released or minimized.
- DECOMMISSIONED
# The access has been permanently removed or retired. Cannot return to an active state.
description: |
The current high-level lifecycle state.
Must be one of PENDING, ACTIVE, INACTIVE, or DECOMMISSIONED.
Allowed Transitions:
1. PENDING: Possible transitions:
- PENDING -> ACTIVE (once approved or successfully provisioned)
- PENDING -> INACTIVE (if provisioning fails or the request is canceled)
- PENDING -> DECOMMISSIONED (edge case if we decide to discard the request permanently)
2. ACTIVE: Possible transitions:
- ACTIVE -> INACTIVE (temporarily disabled, off, or parked)
- ACTIVE -> DECOMMISSIONED (end-of-life; final teardown)
3. INACTIVE: Possible transitions:
- INACTIVE -> ACTIVE (reactivating if quotas and rules allow)
- INACTIVE -> DECOMMISSIONED (final removal)
4. DECOMMISSIONED: No valid transitions from DECOMMISSIONED (terminal state).

reason_code:
  type: string
  description: |
    Optional detail explaining WHY the current status was set.
    For security or forced transitions (e.g., from `ACTIVE` to `INACTIVE` due
    to a vulnerability), you SHOULD provide a relevant reason code.
    If we want to offer a controlled set of reason codes, we can use an enum:

  #enum:
  #  - USER_REQUEST
        # user manually switched off or cancelled
  #  - SECURITY_ISSUE
        # suspended due to a security concern
  #  - BILLING_ISSUE
        # billing or quota problem triggered deactivation
  #  - PROVISIONING_ERROR
        # provisioning failed when transitioning from `PENDING` to `ACTIVE`
  #  - REVOCATION
        # admin/policy-based revocation
  #  - EXPIRED
        # time-based or contract-based expiration
  #  - REPLACED
        # replaced by a new instance or updated resource

required:
- status
# 'reason_code' can be optional: we can keep it out of "required"
# unless we agree to have it in every scenario. Otherwise application logic will enforce
# reason_code presence in critical transitions.

[tlohmar]

thanks @sergiobrisio for the elaborated response. Becomes a bit tricky to provide feedback on individual aspects....lets try

<<A Media Producer creates a Dedicated Network for 20th September from 9am-2pm in central London to cover the London Marathon. They have 10 cameras, each of which requires access at all times, as well as a mobile camera that will be used occasionally.>>
In this scenario <<what state are the camera’s in? are they pending (until 20th?) or Active?>>
Simplified: PENDING/ACTIVE/INACTIVE/DECOMMISSIONED
Considered that all the mechanisms have been tested:
The 10 Cameras should probably be progressively moved from PENDING to ACTIVE state just few minutes before the London marathon would pass near the specific Camera, in order to consume the available network quotas for the slice as late as possible.

hmm, the DN Accesses APIs is about giving access for a device to a network. Of course, this API can also be used to restrict connectivity activation (e.g. PDU Session establishment) and connectivity usage (i.e. sending IP packets), but these are actually subsequent steps. And, devices typically not trigger connectivity activation, based network access activation.
In the given scenario, all 11 cameras are managed by the same Media Producers. Most Media Producers control devices remotely, so that the camera operators can focus on the creative capturing of the scene. When a camera has no access to the dedicated network, it either cannot be remotely controlled or uses another network simultaneously.

One solution could be, that all 11 cameras have an active access to the network (since all are under control of the Media Producer). The network profile is designed in such a way, that each camera is allowed to maintain a low bitrate session for remote controlling the device. The Media Producer may reduce the quality of some of the 10 camera, when the 11th (occasionally used camera) need to get full quality (bounds defined by the aggregated [Ul|DL] Throughput).

"moved from PENDING to ACTIVE state just few minutes before the London marathon would pass near the specific Camera": This is another possible solution, specifically when the Media Producer does not fully trust the device behavior. Note, that the camera needs to get triggered to activate connectivity.

The CSP could check if the available quotas for the specific slice are enough to get the additional camera inside the slice...

I believe there are also other admission control tools in the network for doing these types of checks.

So for this case a PENDING status should be mandatory, not only for the @tlohmar consideration in (1) on provisioning time, but also to perform any kind of check on available quotas, or anytime a camera has to become (newly) ACTIVE, right?

Sure. However, the dedicated network may allow devices to use two different QOS profiles, e.g. one low bitrate and one higher bitrate qos profile. The available quota (aggregated throughput) may only be exceeded, when too many devices use the higher bitrate qos profile simultaneously.

Now in ACTIVE state, let's suppose that a security issue is happening, for example the additional camera has been hacked...

Which entity is deciding, that a camera is hacked? The CSP or the ASP (Media Producer as API consumer)? I suspect, that the CSP cannot really differentiate between intended-behavior and abnormal-behavior.

The state change from ACTIVE to INACTIVE should handle the end of the marathon, so the laziest athletes could be the triggers to switch off the fixed cameras...

Maybe the first action is to stop the capturing & sending process. Not sure, whether the access for the device needs to get inactivated immediately.

<<Do the individual cameras need to know their state? >>

yes, devices should preferably only activate connectivity, when access to the network is active as well. Otherwise, resources are consumed for just sending an "no access" error message.

Not sure, whether active is a good state name. It can be translated to device has_access to the network. The device does not necessarily need active connectivity, like an established PDU Session.