diff --git a/Notes.md b/Notes.md
index 78a9c474d80fee41a925ec7508a9bf658105d70b..fb5328f61d74d2082c7589b51686dc8da8ffec32 100644
--- a/Notes.md
+++ b/Notes.md
@@ -1,3 +1,7 @@
+[1] done
+[2] bis 2.10 done
+[12] fehlt Kapitel 5 bis ---
+
 # Paper / Drafts
 
 * Requirements and Challenges for IoT over ICN
diff --git a/paper/paper.pdf b/paper/paper.pdf
index 2d407be4eb2287a1a0cd1f6a3c2437f4d46619fb..53defc495cc3369691ee02aefc9ee09037954659 100644
Binary files a/paper/paper.pdf and b/paper/paper.pdf differ
diff --git a/paper/paper.tex b/paper/paper.tex
index 58bc75725eaddadfe6ae5792d70f361a0973632b..10e2690d4c2ad2dcbf6dfdbd8d7e78beb23943e0 100644
--- a/paper/paper.tex
+++ b/paper/paper.tex
@@ -98,7 +98,7 @@
 % When switching from latex to pdflatex and vice-versa, the compiler may
 % have to be run twice to clear warning/error messages.
 
-
+\usepackage{comment}
 
 
 % *** CITATION PACKAGES ***
@@ -340,7 +340,7 @@
 % affiliations
 \author{\IEEEauthorblockN{Dorian Grosch}
 \IEEEauthorblockA{Freie Universit\"at Berlin\\
-Berlin, Deutschland\\
+Berlin, Germany\\
 Email: \href{mailto:doriangrosch@zedat.fu-berlin.de}{doriangrosch@zedat.fu-berlin.de}}
 }
 
@@ -381,13 +381,11 @@ Email: \href{mailto:doriangrosch@zedat.fu-berlin.de}{doriangrosch@zedat.fu-berli
 % As a general rule, do not put math, special symbols or citations
 % in the abstract
 \begin{abstract}
-The abstract goes here.
+As the usage of personal computing devices evolves heavily towards consuming content from the network, Internet architecture research shifts from a purely host-centric communication model to a information-centric one. This new paradigm is also well suited to the emerging Internet of Things (IoT), as it combats address-space scarcity, aims for efficient and reliable data delivery and emphasizes security with self-certifying content. Security and privacy considerations are key considerations in the laying of the foundation of Information Centric Networking (ICN). This paper will give an overview of the ICN architecture and put it in relation to the specific requirements of the IoT. Furthermore, to highlight the security aspects of ICN-based IoT, a secure ICN architecture for IoT will be presented and discussed in the light of further work.
 \end{abstract}
 
 % no keywords
-
-
-
+Keywords: Information Centric Networking, ICN, Internet of Things, IoT, security, privacy
 
 % For peer review papers, you can put extra information on the cover
 % page as needed:
@@ -484,18 +482,71 @@ The abstract goes here.
 
 \section{Introduction and Motivation}
 
-\cite{IEEE:xylomenos}
+The current Internet architecture is based on the design principles and requirements present at its conception. The network's aim was to share resources and establish long-range data communication from one end-point to another. This was made possible by packet forwarding mechanisms on the network layer, which initially were designed without significant security considerations in mind. Over time, the Internet evolved and grew in complexity and size, with additional security and safety mechanisms being added as weaknesses of the network architecture began to show. 
+
+However, new challenges surface with the usage of the Internet changing from a research network to a global media and data delivery system: scalable content distribution, mobility, security, and trust are in the focus of current Internet architecture research. \cite{IEEE:xylomenos} To address this issues and the limitations of the traditional Internet architecture, new network paradigms are being developed, such as Information Centric Networking (ICN).
+
+With the key mechanisms of naming information at the network layer, caching and storing content in the network and native multicast functionality, ICN is put forward as a promising candidate of a Future Internet architecture. \cite{IEEE:xylomenos} Additionally, efficient and reliable data delivery, mobility management and security and privacy considerations are being built into the network architecture. 
+
+The need for ICN highlights the shift of the Internet from a pair-wise communication mechanism between end hosts to a information dissemination system. This is being reflected in the Internet of Things (IoT), a networking trend whereby an ever increasing number of low-power sensor and actuator devices are being connected to the Internet. With data being created at these new end-points, the need for efficient naming and addressing schemes for billions of devices (and contents) arises. Since these devices often need to preserve battery power, the issue of data availability needs to be handled: a possible solution lies in the in-network caching mechanism of ICN. \cite{IEEE:arshad}
+
+This paper aims to present the ICN architecture and highlight the specific requirements of IoT when applying ICN as a possible network paradigm to it. To showcase some specific work done on the security and privacy aspects of ICN in IoT, a proposed ICN architecture with focus on security \cite{IEEE:sicari} will be discussed. Finally, the concluding remarks will summarize the topics covered and discuss further work to be done in ICN research.
 
 \section{Information Centric Networking}
 
+The ICN approach to networking is characterized by the decoupling of information from its sources. Under this paradigm, the location and identity of data need not be the same. A naming scheme is used to address information and data, which reshapes the information retrieval mechanism to emphasize the receiver as the driver of the data exchange: no data can be received if the receiver does not explicitly request it using its unique name. \cite{IEEE:xylomenos} The network routes such requests and selects the best source for satisfying them, taking into account metrics like efficiency and speed.
+
+The emergence of Content Delivery Networks (CDNs) shows another weak point of the traditional Internet architecture: there is a need for content caching, as user crowds increasingly request the same content in a short time span -- a phenomenon called \textit{flash crowds}. \cite{IEEE:xylomenos} ICN incorporates the solution to this into the network structure: in-network caching is designed to bring (copies of) content closer to the consumers and thereby alleviate network load by using multicast forwarding. Since the content is named, and as such is discernible to the network layer, access control mechanisms can be implemented directly in the distribution mechanism itself. \cite{IEEE:xylomenos} 
+
+Mobility is another issue that faces future Internet architectures like ICN. Hosts are often and increasingly non-fixed, roaming through physical space and connecting to a multitude of different networks. To send and receive data in such situations calls for a new communication model. ICN uses the publish/subscribe model, which differs from its traditional variant. The publish operation announces the availability of information to the network, while the subscribe operation requests available information from the network. Inside the network, brokers provide the functionality to match subscriptions with publications and provide additional services. The publish/subscribe operations are decoupled in time, with mobile hosts simply reissuing publication announcements and subscription requests when switching networks. \cite{IEEE:xylomenos}
+
+While traditional Internet architectures are sender-driven, the publish/subscribe model gives the receiver initiative power. This is relevant for network security, since data flow occurs only when a host requests some publicly announced data from the network. In this way unwanted data in the network is reduced and the network can be protected against some malicious attacks like \textit{Denial of Service}. Also, since the data flowing through the network is self-certifyingly named (e.g. using a hash of the data), malicious data can be filtered by the network itself without the need for add-on host software like firewalls. These operations are performed by intermediate parties which decouple the sender from the receiver and in this way can contribute to user privacy. \cite{IEEE:xylomenos}
+
 \subsection{Requirements and Challenges}
 
+In designing and building a new Internet architecture, one has to identify the flaws in the current one and identify challenges to be met. The setting of technical and architectural requirements is the first step in builing a new network better suited for applications of the future. 
+
 \cite{IETF:zhang}
 \cite{IETF:ravindran}
+\cite{IEEE:arshad}
+
+\
+
+\subsubsection{Technical Requirements and Challenges}
+
+\
+
+\
+
+A future Internet architecture like ICN has to take into account that the connected devides will be very different in terms of available resources, ranging from network nodes with abundant energy, computing power, storage and bandwith to IoT devices with severe resource constraints. 
+
+Furthermore, the means of connecting to the Internet will be extremely heterogeneous. Especially with IoT devices collecting sensor data from sensitive sources (e.g. from smart home environments) security and privacy are strong requirements. \cite{IETF:zhang}
+
+There is a strong need for the use of caching mechanisms. The network needs to support efficient resolution of cached copies of requested data. \cite{IETF:zhang}
+
+Reliable communication has to be guaranteed for application with high QoS requirements. These requirements extend to the network: seamless mobility support, efficient routing, QoS aware routing, redundancy at all levels and support for rich communication patterns, especially in the presence of intermittent or extreme connection problems. \cite{IETF:zhang}
+
+\
 
-\subsubsection{Technical Requirements}
+\subsubsection{Architectural Requirements and Challenges}
 
-\subsubsection{Architectural Requirements}
+\
+
+\
+
+A future Internet architecture like ICN has to accomodate a huge number of connected devices, of which a significant part are going to be mobile. It has to support interactions with applications across boundaries of administration and domains. \cite{IETF:zhang} Architectural requirements are scattered over all of its functional domain.
+
+The central requirements for the naming mechanism of ICN are that names are to be persistent and secure, and provide advantages in comparision to traditional host-centric architectures. An ICN system should register, update and resolve a given name without long latencies. \cite{IETF:zhang}
+
+Scalability is another central requirement which spans over multiple levels of the architecture: naming, name resolution, data routing, forwarding and security. \cite{IETF:zhang}
+
+Two kinds of internet traffic have to be considered: local area traffic and wide area communications. Both of these kinds of traffic demonstrate a certain periodicity and burstiness in the IoT context. The expected traffic shape has to be accounted for in designing the network. \cite{IETF:zhang}
+
+Since mobility is a central aspect of future Internet architectures, the spatial and temporal context of network connections have to be considered. Depending on application domain, locally close devices should be able to form "clusters" to communicate effectively with one another or form long-term connections based upon social contacts. \cite{IETF:zhang}
+
+Security and privacy are fundamental requirements and challenges for ICNs, since in the IoT physical objects are made accessible through a wide network and are often integrated within critical infrastructure and industrial systems. Security requirements comprehend trust management, data integrity, authentication and access control. Privacy requirements are to protect the content and the context arout data from IoT devices. \cite{IETF:zhang}
+
+The network is expected to be self-organizing to the degree that it is capable of quickly discovering heterogeneous and relevant devices, data and services based on application context. To enable this, the infrastructure and application specific logics need to be decoupled. \cite{IETF:zhang}
 
 \subsection{Design Choices}
 
@@ -505,19 +556,80 @@ The abstract goes here.
 
 \subsubsection{Naming}
 
+\ 
+
+\
+
+Hierarchical names have the advantage that scalability is easily achieved by name aggregation. Routing table size can be extensively reduced when names are aggregated in a way that reflects the network topology. Challenges occur when mobile hosts change the topology of the network. \cite{IEEE:xylomenos}
+
+In contrast, flat names are not bound to a location by virtue of their name: they are location-independent and support mobility better than their counterparts. However, by their nature they are difficult to aggregate and can require mechanisms like \textit{Distributed Hash Tables} to manage. \cite{IEEE:xylomenos} 
+
+Names can be either human-readable or self-certifying. Due to this, ICN architectures that want to combine both aspects have to rely on additional systems that bind two kinds of names to the same data. \cite{IEEE:xylomenos} 
+
+Although data can be composed for computational and analytical uses, ICN architectures should only support directly addressable data objects. \cite{IETF:lindgren}
+
+\ 
+
+\subsubsection{Name Resolution and Data Routing}
+
+\ 
+
+\
+
+Different approaches are used for resolving names to data sources. ICN architectures based on hierarchical names want to get the scaling benefits without the limitations imposed by the location-identity binding. Architectures using flat names however face the problem of handling a name space without being able to aggregate it. \cite{IEEE:xylomenos} A hybrid approach tries to combine both schemes by concatenating flat names to aggregate them. This would reduce the huge routing table size otherwise needed for flat name routing. \cite{ACM:ghodsi}
+
+Data routing can be coupled or decoupled from name resolution. In the first case, routing information is collected while the name of the requested data is being resolved. The path taken can be stored in the request packets or by the content routers themselves. Usually the data transmission takes the inverse path of the name resolution. \cite{IEEE:xylomenos}
+
+In the second case, the route the data transmission takes is independently calculated. This can be done by a indipendent system that is part of the ICN architecture or by using traditional IP-based Internet routing once the address of the data publisher is discovered by name resolution. \cite{IEEE:xylomenos}
+
+\ 
+
 \subsubsection{Caching}
 
+\ 
+
+\
+
+Caching can be realized in two basic ways. On-path caching provides a short-circuiting of data requests by the router that receives them. Instead of relaying a request to the data source, the router can provide the data if the routers cache contains it. On-path caching is facilitated by the coupling of name resolution and data routing, as there are more opportunities to make use of opportunistic caching along the resolution path. \cite{IEEE:xylomenos}
+
+In off-path caching, external caches announce their contents to the name resolution system. It can then route data requests to the external caches if this would provide a performance gain. \cite{IEEE:xylomenos}
+
+\ 
+
 \subsubsection{Actuation}
 
+\ 
+
+\
+
+blank
+
+\ 
+
 \subsubsection{Decoupling}
 
+\ 
+
+\
+
+blank
+
+\ 
+
 \subsubsection{Security and Privacy}
 
+\ 
+
+\
+
+In contrast to the traditional Internet architecture, the focus of ICN data security lies on the data itself, not the communication channel used to transmit it. Confidentiality and integrity of the data are tightly related to the naming structure, since they are ensured by self-certification of names. Through this, ICN automatically guarantees the integrity of the data regardless of its source. Furthermore, the data itself can be signed and encrypted. \cite{IETF:lindgren} These measures do not rely on the trustedness of hosts or communication channels, but they require at least some level of trust in the name resolution system of the architecture. \cite{IEEE:xylomenos}
+
 \cite{IRTF:pentikousis}
 \cite{IRTF:kutscher}
 \cite{IEEE:sicari}
 \cite{SIGCOMM:ion}
 
+\begin{comment}
 \section{Named Data Networking}
 
 \cite{NDN:zhang}
@@ -539,16 +651,58 @@ The abstract goes here.
 \subsection{Further work}
 								
 %\subsubsection{Naming and content}
+\end{comment}
 
 \cite{IEEE:hamdane}
 
-\section{Secure Internet Of Things}
+\section{Internet Of Things}
+
+[Definition of IoT here] %TODO
+
+ICN seems to be a good choice as an architecture for the Internet of Things, since the applications and usage of the IoT often embody information centric usage patterns. However, IoT differs in some aspects from the originally intended use case of ICN because of the high heterogeneity of connected devices and the very high rate of newly generated information, among others. Because of this, a good trade-off has to be found between a host-centric and information-centric approach. \cite{IETF:lindgren}
 
 \subsection{Specific aspects for IoT}
 
+While the retrieval and dissemination of sensor data from IoT devices is well served by an ICN paradigm, controlling actuators in IoT devices appears to be less easily accomplished. \cite{IETF:lindgren}
+
+In the real world, ICN networks will be most likely to coexist with already existing Internet protocols and architectures, often as overlay networks to the traditional Internet. \cite{IETF:lindgren}
+
+Since IoT data objects are usually small, there is a trade-off involved in that these numerous small objects result in a larger naming overhead. \cite{IETF:lindgren}
+
+To support scalability of ICN networks in IoT it is essential to make the named data object immutable. This prevents cache inconsistencies, but also has the consequence that dynamic data has to be modelled as a stream of immutable data objects, which can be more resource-intensive. \cite{IETF:lindgren}
+
+IoT data is often modelled as a stream, e.g. a stream of temperature readings of a smart building. If access to singular values in the stream is wanted, it could be beneficial to support sequence numbers in data requests. If the latest value of a stream is seeked, the corresponding sequence number could be obtained by meta-data transmitted while subscribing or by adaptive sequence number probing. \cite{IETF:lindgren}
+
+Since time is an important propery of IoT data, it could be useful to extend an ICN system to embed a mapping from sequence numbers of streams of data to time values. \cite{IETF:lindgren}
+
+The decoupling of senders and receivers is an important feature of ICN for IoT, since it allows for IoT devices to be offline for certain intervals of time (e.g. to save battery power). The caching mechanism of ICN ensures that data objects are available even when the device is offline. \cite{IETF:lindgren}
+
+ICN does not provide processing, transformation or aggregation of data. This is a deliberate design choice, as such operations are better performed on intermediate processing nodes, leaving the network to its main function of distributing data. \cite{IETF:lindgren}
+
+\
+
+\subsubsection{Actuators}
+
+\
+
+\
+
+IoT devices often have actuators that need to be remotely controlled. If this is to be accomplished through ICN, the functionality of the actuators have to be mapped to (the requesting of) named data. Possible scenarios are an IoT device periodically requesting its supposed state from the network or invoking its actuation function in response to a received data request. In these cases caching can be problematic, if it hinders requests to arrive at the IoT device. \cite{IETF:lindgren}
+
+\
+
+\subsubsection{Security}
+
+\
+
+\
+
+
+
 \cite{baccelli}
 \cite{IEEE:quevedo}
 \cite{IEEE:abane}
+\cite{IEEE:arshad}
 
 \subsection{Scenario: Sensor network}
 
@@ -558,6 +712,10 @@ The abstract goes here.
 \subsection{Further work}
 
 \cite{IEEE:garcia}
+
+\section{A Secure ICN-IoT Architecture}
+
+\cite{IEEE:sicari}
 
 \section{Conclusion}
 
@@ -593,23 +751,23 @@ The abstract goes here.
 
 %1
 \bibitem{IETF:lindgren}
-Lindgren et al., ​Proposed Design Choices for IoT over Information Centric Networking, \url{https://datatracker.ietf.org/doc/draft-lindgren-icnrg-designchoices/}
+Lindgren et al., Work in progress: ​"Proposed Design Choices for IoT over Information Centric Networking", \url{https://datatracker.ietf.org/doc/draft-lindgren-icnrg-designchoices/}
 
 %2
 \bibitem{IETF:zhang}
-Zhang et al., Requirements and Challenges for IoT over ICN. \url{https://datatracker.ietf.org/doc/draft-zhang-icnrg-icniot-requirements/}
+Zhang et al., Work in progress: "Requirements and Challenges for IoT over ICN". \url{https://datatracker.ietf.org/doc/draft-zhang-icnrg-icniot-requirements/}
 
 %3
 \bibitem{IETF:ravindran}
-Ravindran et al., Design Considerations for Applying ICN to IoT, \url{https://datatracker.ietf.org/doc/draft-irtf-icnrg-icniot/}
+Ravindran et al., Work in progress: "Design Considerations for Applying ICN to IoT", \url{https://datatracker.ietf.org/doc/draft-irtf-icnrg-icniot/}
 
 %4
 \bibitem{IRTF:pentikousis}
-Pentikousis et al., RFC7945, Information-Centric Networking: Evaluation and Security Considerations, \url{https://tools.ietf.org/html/rfc7945}
+Pentikousis et al., RFC7945, "Information-Centric Networking: Evaluation and Security Considerations", \url{https://tools.ietf.org/html/rfc7945}
 
 %5
 \bibitem{IRTF:kutscher}
-Kutscher et al., RFC7927, Information-Centric Networking (ICN) Research Challenges, \url{https://tools.ietf.org/html/rfc7927}
+Kutscher et al., RFC7927, "Information-Centric Networking (ICN) Research Challenges", \url{https://tools.ietf.org/html/rfc7927}
 
 %6
 \bibitem{NDN:zhang}
@@ -689,6 +847,18 @@ doi: 10.1109/W-FiCloud.2018.00046
 \bibitem{SIGCOMM:ion}
 Mihaela Ion, Jianqing Zhang, and Eve M. Schooler. 2013. Toward content-centric privacy in ICN: attribute-based encryption and routing. In Proceedings of the 3rd ACM SIGCOMM workshop on Information-centric networking (ICN '13). ACM, New York, NY, USA, 39-40. DOI: https://doi.org/10.1145/2491224.2491237
 \url{https://dl.acm.org/citation.cfm?id=2491224.2491237}
+
+%20
+\bibitem{IEEE:arshad}
+S. Arshad, M. A. Azam, M. H. Rehmani and J. Loo, "Recent Advances in Information-Centric Networking-Based Internet of Things (ICN-IoT)," in IEEE Internet of Things Journal, vol. 6, no. 2, pp. 2128-2158, April 2019.
+doi: 10.1109/JIOT.2018.2873343
+\url{https://ieeexplore.ieee.org/document/8478349}
+
+%21
+\bibitem{ACM:ghodsi}
+A. Ghodsi, T. Koponen, J. Rajahalme, P. Sarolahti, and S. Shenker, "Naming in content-oriented architectures" in ACM Workshop on Information-Centric Networking (ICN), 2011.
+doi: 10.1145/2018584.2018586
+\url{https://dl.acm.org/citation.cfm?id=2018584.2018586}
 
 \end{thebibliography}
 
diff --git a/references/Secure_ICN-IoT Architecture-ICC-2017.pdf b/references/Secure_ICN-IoT Architecture-ICC-2017.pdf
deleted file mode 100644
index 37ad34aa26b5e6b4491a0bfd99d5b64599b28427..0000000000000000000000000000000000000000
Binary files a/references/Secure_ICN-IoT Architecture-ICC-2017.pdf and /dev/null differ