diff --git a/documentation/design/05-implementation.md b/documentation/design/05-implementation.md
index 85fff63c8e70b434f7c984b06cfb28308d1df562..be6e70b2738d24ca4dc20c3f6f6be2dce635c36c 100644
--- a/documentation/design/05-implementation.md
+++ b/documentation/design/05-implementation.md
@@ -74,8 +74,8 @@ belonging together.
 ### neo4j
 Due to the fact that network topologies, with all their elements and connections, 
 can be represented well by a graph, the choice of a graph database for persistence was obvious.
-After some initial experiments with RedisGraph, Neo4j was chosen, 
-because Neo4j allows the use of multiple labels (for nodes as well as edges) 
+After some initial experiments with RedisGraph, neo4j was chosen, 
+because neo4j allows the use of multiple labels (for nodes as well as edges) 
 and offers a wider range of plugins.
 
 The current implementation offers the possibility to persist different network elements 
@@ -114,6 +114,59 @@ stored as neo4j nodes. However, with this current variant it is not possible, as
 [Topology Inventory](#topology-inventory), to represent topologies that are hierarchically 
 interdependent, since neo4j does not allow relations to be stored as properties (as described [here](https://neo4j.com/docs/cypher-manual/current/syntax/values/#structural-types)
 
+For the reason mentioned above, a more complex idea for persistence is available for the further development, which hopefully allows us to persist and map network elements, PNDs and topologies with all their hirarchical dependencies.
+
+The following figure tries to visualize this idea. The main difference is, that for the different topologies separate nodes are created, to which so-called links belong. The links themselves form a connection between the respective network elements. A link can have several layer protocols, like OTUCN, ODUCN etc.
+
+```mermaid
+graph TD
+subgraph "dependencies of topologies"
+    logical1 -->|related_to| physical
+    logical5 -->|related_to| physical
+    logical3 -->|related_to| logical1
+end
+
+subgraph "every node belongs to a specific PND"
+  Node1 -->|belongs_to| PND
+  Node2 -->|belongs_to| PND
+  Node3 -->|belongs_to| PND
+  Node4 -->|belongs_to| PND
+  Node5 -->|belongs_to| PND
+end
+
+subgraph "relationship between nodes (nodes can be linked by 0...n links)"
+  lp2[link_physical]
+  lp3[link_physical]
+  lp4[link_physical]
+  lp5[link_logical1]                      
+  lp2 --> |connects| Node4
+  lp2 --> |connects| Node2
+  lp3 --> |connects| Node2
+  lp3 --> |connects| Node3
+  lp4 --> |connects| Node2
+  lp4 --> |connects| Node5
+  lp5 --> |connects| Node1
+  lp5 --> |connects| Node2
+end
+
+subgraph "links are part of a topology"
+lp1[link_physical]
+lp1 --> |connects| Node1
+lp1 --> |connects| Node2
+lp1 --> |part_of| physical
+end
+
+subgraph "links can contain 1...n layers"
+lp2 --> |contains| ODUH
+lp2 --> |contains| OTUCN
+lp2 --> |contains| ODUCN
+end
+```
+The above idea is not yet approved and there are still open questions.
+- Is there a better solution for the assumption that there are several different physical connections between the same nodes than separate link nodes between them?
+- Can topologies run over different PNDs -> membership to different PNDs?
+- Where can we benefit from using different layers? (e.g. possible saving of unnecessary relations between nodes)
+- ...
 
 ## YANG to code