Time budget (AX2Go and virtual network) - AXM Plus

The term “time budget” occurs in two different contexts:

  • AX2Go: Offline time budget (in days)
  • Virtual network: Dynamic time window

Both means that an identification medium can only be used for a limited time before the time budget needs to be topped up again. When topping up, the system checks whether authorisation changes have been made or whether the identification medium has even been blocked.

 

AX2GO: Offline time budget (in days)

Virtual network: Dynamic time window

Adjustability

  • Max. 30 days since last top-up
  • Adjustable to the exact day
  • Max. 255 hours (approx. 10 days) or
  • up to a given time from topping up (e.g., from topping up until 8 p.m.)
  • Adjustable to the exact hour

Topping up through

AXM service.

As soon as the AX2Go and the AXM service both access the cloud and thus see each other, the time budget is fully topped up again.

Virtual network gateways

Top-up frequency

With a few exceptions, the smartphone with the AX2Go is permanently connected to the Internet and thus to the cloud. This means that the time budget is fully topped up each time the AXM service connects to the cloud.

The AXM service connects to the cloud immediately in the event of important changes (e.g. changes to authorisations); otherwise, it connects about twice a day.

The time budget is topped up again once the identification medium is activated at the gateway, provided it has not been blocked.

Intended purpose

A smartphone could be set to flight mode and thus the connection to the AXM service could be intentionally interrupted. In this case, a change in authorisation would never reach the AX2Go.

Offline time budget (in days)” forces all AX2Go users to allow a connection between the AX2Go and AXM service on a regular basis. This prevents flight mode from being misused and inadvertently use a permission permanently.

In the virtual network, “Dynamic time window” performs two tasks:

  1. Forcing identification media to go to gateway
  2. Time limitation of authorisation in the event of lost identification media

In the virtual network, data is transported from the gateway to the locking devices and back again using identification media. The more often the identification media are presented to the gateway, the more effectively data exchange works. With a limited time budget, you can ensure that all users go to the gateway on a regular basis.

After deactivation (for example, following its loss), a stolen identification medium may not be utilised beyond the set time limit. Wholly independent of whether the deactivation was carried out at the locking device. The stolen identification medium’s time budget can no longer be renewed and thus expires.

Example (normal operation)

Example: time budget set to 30 days.

A user’s AX2Go is connected to the AXM service via the cloud. Since the user is still authorised, the time budget is renewed to the full 30 days.

The locking system administrator closes their laptop and goes on vacation for three weeks.

However, since the user’s AX2Go has a time budget of 30 days, the AX2Go can be used without problems during the locking system administrator’s entire vacation leave.

After the locking system administrator returns, they restart their laptop. The AXM service connects to the cloud and the user’s time budget is topped up.

The user’s AX2Go functions uninterrupted at all times.

Example: Budgeted time set at 10 hours.

A user presents their identification medium on the gateway. The gateway connects to the database and determines that the identification medium has not been blocked and renews the time budget.

The user may subsequently use their identification medium for 10 hours.

They then activate their identification medium again at the gateway and receive a new time budget.

Example (problem)

Example: time budget set to 7 days.

An authorisation is withdrawn from a AX2Go user. However, since the user knows that this authorisation is to be revoked and they want to operate the locking device at a later stage without being detected, they activate flight mode to prevent authorisation from being revoked.

The AX2Go can no longer establish a connection to the cloud, so the time budget of the user concerned is no longer renewed.

After the 7 days have elapsed, the user can no longer operate a locking device with their AX2Go and is forced to allow an online connection. This means that the revoked authorisation also reaches its AX2Go.

Example: Budgeted time set at 10 hours.

An identification medium is reported as stolen and is subsequently deactivated by the locking system administrator. Over time, the blocked IDs are distributed to the locking devices in the virtual network. However, some more remote locking devices have still not received a blocked ID ten hours later.

However, the stolen identification medium can no longer be used on these locking devices. The time budget has expired and there will be no renewal due to deactivation.