diff --git a/docs/features/communication/index.rst b/docs/features/communication/index.rst
index f432f03ba7e..5270d68d46b 100644
--- a/docs/features/communication/index.rst
+++ b/docs/features/communication/index.rst
@@ -30,6 +30,7 @@ Communication
docs/**/index
ipc/index
+ some_ip_gateway/index
Feature flag
============
diff --git a/docs/features/communication/some_ip_gateway/architecture/index.rst b/docs/features/communication/some_ip_gateway/architecture/index.rst
new file mode 100644
index 00000000000..4b3e79164bb
--- /dev/null
+++ b/docs/features/communication/some_ip_gateway/architecture/index.rst
@@ -0,0 +1,180 @@
+..
+ # *******************************************************************************
+ # Copyright (c) 2024 Contributors to the Eclipse Foundation
+ #
+ # See the NOTICE file(s) distributed with this work for additional
+ # information regarding copyright ownership.
+ #
+ # This program and the accompanying materials are made available under the
+ # terms of the Apache License Version 2.0 which is available at
+ # https://www.apache.org/licenses/LICENSE-2.0
+ #
+ # SPDX-License-Identifier: Apache-2.0
+ # *******************************************************************************
+
+.. _some_ip_gateway_architecture:
+
+SOME/IP Gateway Architecture
+############################
+
+.. toctree::
+ :titlesonly:
+
+Context View
+============
+SOME/IP Gateway on one side is a regular participant in IPC and uses the according mechanisms to publish
+data or to subscribe to data. As such it will need to know and understand the data types that are used in
+the IPC network.
+
+It also is a participant in the SOME/IP network and provides services for the service oriented communication.
+This shall be possible by including SOME/IP stacks that are AUTOSAR compliant.
+
+There need to be some components between the two communication networks as data types and their according representations and
+transmission cadence can be different. Translation of data types could be handled in some translation module
+that might be independent of the rest of the gateway. But buffering / queuing of messages, events, signals
+should be mostly freely programmable by integrators using the SOME/IP gateway.
+
+
+.. figure:: ../assets/some_ip_gateway_architecture.drawio.svg
+ :align: center
+ :name: _some_ip_gateway_architecture
+
+ General overview of SOME/IP Gateway
+
+Structural View
+===============
+SOME/IP stacks as supplied by AUTOSAR vendors mostly are available as QM only.
+In the case that SOME/IP implementations are not developed under ASIL-B constraints, adequate measures need to be taken to
+separate this QM component from the otherwise ASIL-B compliant components. This may be achieved through separate processes,
+which again will require dedicated inter-process-communication between the SOME/IP-stack and the rest of the gateway.
+It is preferred to avoid such additional IPC.
+
+.. figure:: ../assets/some_ip_gateway_details.drawio.svg
+ :align: center
+ :name: _some_ip_gateway_details
+
+ Detailed components view of SOME/IP Gateway
+
+E2E Considerations
+==================
+To cope with SOME/IP stack just being QM, we need to prepare for end-to-end protection. The goal shall be to
+do the E2E protection/check **as centrally as possible** in the gateway. Unfortunately, the centralized end-to-end
+check cannot be done for all relevant E2E properties. The following table proposes where the corresponding E2E properties shall
+checked.
+
+.. list-table:: E2E properties
+ :widths: 20 50 5 5
+ :header-rows: 1
+
+ * - Protection Property
+ - Purpose
+ - Gateway
+ - IPC Client
+ * - CRC
+ - Detects data corruption in the payload and metadata.
+ - x
+ -
+ * - Counter
+ - Detects message loss, duplication, or reordering.
+ - x
+ - x
+ * - Alive Counter
+ - Detects if the sender is still active or stuck/frozen
+ - x
+ - x
+ * - Data ID
+ - Identifies the data format version to prevent misinterpretation.
+ -
+ - x
+ * - Timeout
+ - Detects if no message is received within a defined time window.
+ -
+ - x
+
+E2E Design and Interface Considerations
+---------------------------------------
+As mentioned above, not all E2E checks can be kept hidden within the gateway. For some problems it is up to the application to decide
+whether it is still valuable to access and process the data. This is in particular true for duplication or re-ordering issues.
+Therefore, it is required to pass a **tupel** consisting of the **payload data** as well as **supplementary E2E metadata and error information**
+to the IPC clients to enable the client to individually judge on particular E2E issues.
+
+* The API design needs to put the payload information as well as the additional E2E metadata as close as possible together to easily enable and motivate clients to consequently check for potential errors.
+* Additional metadata and error information needs to be incorporated into regular mw::com user interface
+* Error related interface design needs to be highly optimized for the "good case" to have an optimized support for the common IPC case
+* Assumptions of Use need to be provided to force the user to check for the (E2E-) result
+* Additional E2E metadata to be handed over to the clients:
+
+ * Counter, slightly different interpretation depending on profile, n/a in case the profile doesn't support it
+ * Data ID, n/a in case the profile does not support it or if the Data ID is not explicitly transmitted like in profile 22
+ * Profile identification, required to properly interpret E2E attributes like "Counter". (Could be either an "Alive Counter" or a "Sequence Counter" depending on the profile)
+ * Detailed, profile specific error code (enum)
+
+* Proposed Error Enumeration
+
+ * No E2E error
+ * CRC Error
+ * Sequence error (further sub-qualification in loss, duplication, reordering is up to the client based on the counter)
+
+.. note::
+ CRC Errors might cause problems with corrupted service / instance IDs, as such messages might not get forwarded to the correct recipient.
+ This requires further discussion during implementation phase.
+
+.. note::
+ The proposed error enumeration is an abstraction. Deriving detailed errors
+ based on the E2E metadata is task of the client.
+ For reference, this is the error enumeration of the AUTOSAR specification (R24-11):
+
+ * OK
+ * ERROR
+ * OKSOMELOST
+ * REPEATED
+ * WRONGSEQUENCE
+ * NONEWDATA
+ * SYNC
+ * INITIAL
+
+E2E State Machine Considerations
+--------------------------------
+The E2E (End-to-End) state machine as defined within AUTOSAR E2E protocol provides a summarized result
+about the overall health and state of a communication channel. Unlike individual E2E Profile Check() functions,
+which assess data validity for a single communication cycle, the state machine aggregates results from multiple Check()
+function invocations over a period. This allows it to determine a more holistic and debounced status of the communication.
+
+Purpose of the E2E State Machine
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The primary purpose of the E2E state machine is to transform instantaneous "per-cycle" check results into a stable,
+long-term communication channel status. This aggregated status is then provided to the consuming application,
+enabling it to make informed decisions about whether the received data can be trusted and used for safety-related functions.
+
+As mentioned above, the E2E state-machine is associated to one communication channel which is in turn associated to exactly one
+individual IPC client. Therefore it is an obvious consequence, that the individual state machine handling and state machine
+configuration is responsibility of the client and not a central responsibility of the gateway.
+Even for the same service different clients may use different state machine configuration.
+The diagram below outlines this distribution of responsibilities.
+
+*Diagram: E2E state machine responsibility associated to IPC client*
+
+.. figure:: ../assets/e2e_state_machine_on_client_side.drawio.svg
+ :align: center
+ :name: _e2e_state_machine_on_client_side
+
+ E2E state machine responsibility associated to IPC client
+
+**Considered Alternative**
+If we allocate the state-machine responsibility to the gateway the distribution of responsibilities would look like in the following diagram
+
+*Diagram: E2E state machine responsibility associated to the gateway*
+
+.. figure:: ../assets/e2e_state_machine_in_gateway.drawio.svg
+ :align: center
+ :name: _e2e_state_machine_in_gateway
+
+ E2E state machine responsibility associated to the gateway
+
+Due to pub/sub nature of mw::com, clients listening on the same topic cannot be separately addressed. Therefore, **the state machine results
+cannot be selectively distributed according to the particular communication channel they belong to**.
+
+**=> Alternative dismissed**
+
+.. note::
+ The End-to-End consideration in this chapter do not yet consider methods.
diff --git a/docs/features/communication/some_ip_gateway/assets/e2e_state_machine_in_gateway.drawio.svg b/docs/features/communication/some_ip_gateway/assets/e2e_state_machine_in_gateway.drawio.svg
new file mode 100644
index 00000000000..cf9ffa295ce
--- /dev/null
+++ b/docs/features/communication/some_ip_gateway/assets/e2e_state_machine_in_gateway.drawio.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/docs/features/communication/some_ip_gateway/assets/e2e_state_machine_on_client_side.drawio.svg b/docs/features/communication/some_ip_gateway/assets/e2e_state_machine_on_client_side.drawio.svg
new file mode 100644
index 00000000000..a3aa7e7592b
--- /dev/null
+++ b/docs/features/communication/some_ip_gateway/assets/e2e_state_machine_on_client_side.drawio.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/docs/features/communication/some_ip_gateway/assets/puml-theme-score.puml b/docs/features/communication/some_ip_gateway/assets/puml-theme-score.puml
new file mode 100644
index 00000000000..fc78e4ca613
--- /dev/null
+++ b/docs/features/communication/some_ip_gateway/assets/puml-theme-score.puml
@@ -0,0 +1,566 @@
+'' The referenced original work is published under MIT license
+'' MIT license: https://github.com/bschwarz/puml-themes/blob/master/LICENSE
+''
+'' conti theme is based on materia theme
+'' Author: Andreas Kaluza
+'' Copyright (c) 2012 by Andreas Kaluza
+''
+'' materia theme based off of the bootstrap theme of the same name
+'' https://bootswatch.com/materia/
+''
+'' Author: Brett Schwarz
+'' Copyright (c) 2019 by Brett Schwarz
+
+!$THEME = "score"
+
+!if %not(%variable_exists("$BGCOLOR"))
+!$BGCOLOR = "transparent"
+!endif
+
+skinparam backgroundColor $BGCOLOR
+skinparam useBetaStyle true
+
+
+
+!$SCORE = "#45ADA8"
+!$BLUE = "#2196F3"
+!$INDIGO = "#6610f2"
+!$PURPLE = "#6f42c1"
+!$PINK = "#e83e8c"
+!$RED = "#e51c23"
+!$ORANGE = "#fd7e14"
+!$YELLOW = "#ff9800"
+!$GREEN = "#4CAF50"
+!$TEAL = "#20c997"
+!$CYAN = "#9C27B0"
+!$WHITE = "#FFF"
+!$GRAY_DARK = "#222"
+!$GRAY = "#666"
+!$PRIMARY = $SCORE
+!$SECONDARY = %lighten($SCORE, 80)
+!$SUCCESS = "#4CAF50"
+!$INFO = %lighten($SCORE, 40)
+!$WARNING = "#ff9800"
+!$DANGER = "#e51c23"
+!$LIGHT = "#fff"
+!$DARK = "#222"
+
+'' *_LIGHT = tint (lighter) of the main color of 80%
+'' *_DARK = shade (darker) of the main color of 80%
+''
+!$FGCOLOR = %darken($SCORE, 80)
+!$PRIMARY_LIGHT = %lighten($SCORE, 40)
+!$PRIMARY_DARK = %darken($SCORE, 40)
+!$PRIMARY_TEXT = %darken($SCORE, 80)
+!$SECONDARY_LIGHT = "#fff"
+!$SECONDARY_DARK = "#cccccc"
+!$SECONDARY_TEXT = %darken($SCORE, 80)
+!$INFO_LIGHT = %lighten($INFO, 40)
+!$INFO_DARK = %darken($INFO, 40)
+!$INFO_TEXT = %darken($SCORE, 80)
+!$SUCCESS_LIGHT = "#70bf73"
+!$SUCCESS_DARK = "#3D8C40"
+!$SUCCESS_TEXT = %darken($SCORE, 80)
+!$WARNING_LIGHT = "#ffad33"
+!$WARNING_DARK = "#CC7A00"
+!$WARNING_TEXT = %darken($SCORE, 80)
+!$DANGER_DARK = "#b7161c"
+!$DANGER_LIGHT = "#B7161C"
+!$DANGER_TEXT = %darken($SCORE, 80)
+
+!procedure $success($msg)
+ $msg
+!endprocedure
+
+!procedure $failure($msg)
+ $msg
+!endprocedure
+
+!procedure $warning($msg)
+ $msg
+!endprocedure
+
+!procedure $primary_scheme()
+ FontColor $PRIMARY_TEXT
+ BorderColor $PRIMARY
+ BackgroundColor $PRIMARY_LIGHT-$PRIMARY
+!endprocedure
+''
+'' Style settings
+''
+
+''
+'' Global Default Values
+''
+skinparam defaultFontName "Arial"
+skinparam defaultFontSize 12
+skinparam dpi 100
+skinparam shadowing true
+skinparam roundcorner 8
+skinparam ParticipantPadding 1
+skinparam BoxPadding 1
+skinparam Padding 1
+skinparam ArrowColor $GRAY
+skinparam stereotype {
+ CBackgroundColor $SECONDARY_LIGHT
+ CBorderColor $SECONDARY_DARK
+ ABackgroundColor $SUCCESS_LIGHT
+ ABorderColor $SUCCESS_DARK
+ IBackgroundColor $DANGER_LIGHT
+ IBorderColor $DANGER_DARK
+ EBackgroundColor $WARNING_LIGHT
+ EBorderColor $WARNING_DARK
+ NBackgroundColor $INFO_LIGHT
+ NBorderColor $INFO_DARK
+}
+skinparam title {
+ FontColor $PRIMARY
+ BorderColor $SECONDARY_DARK
+ FontSize 20
+ BorderRoundCorner 8
+ BorderThickness 1
+ BackgroundColor $SECONDARY_LIGHT-$SECONDARY
+}
+
+skinparam legend {
+ BackgroundColor $SECONDARY
+ BorderColor $SECONDARY_DARK
+ FontColor $DARK
+}
+
+!startsub swimlane
+skinparam swimlane {
+ BorderColor $PRIMARY
+ BorderThickness 2
+ TitleBackgroundColor $SECONDARY_LIGHT-$SECONDARY
+ TitleFontColor $PRIMARY
+}
+!endsub
+
+!startsub activity
+
+skinparam activity {
+ $primary_scheme()
+ BarColor $PRIMARY_DARK
+ StartColor $PRIMARY
+ EndColor $PRIMARY
+ ''
+ DiamondBackgroundColor $PRIMARY_LIGHT
+ DiamondBorderColor $PRIMARY_DARK
+ DiamondFontColor $SECONDARY_TEXT
+ NoteFontColor %darken($SCORE, 40)
+}
+!endsub
+
+!startsub participant
+
+skinparam participant {
+ $primary_scheme()
+ ParticipantBorderThickness 2
+}
+!endsub
+
+!startsub actor
+
+skinparam actor {
+ $primary_scheme()
+ FontColor $DARK
+}
+!endsub
+
+!startsub arrow
+
+skinparam arrow {
+ Thickness 1
+ Color $PRIMARY
+ FontColor $FGCOLOR
+}
+!endsub
+
+!startsub sequence
+
+skinparam sequence {
+ BorderColor $PRIMARY
+ ' For some reason sequence title font color does not pick up from global
+ TitleFontColor $PRIMARY
+ BackgroundColor transparent
+ StartColor $PRIMARY
+ EndColor $PRIMARY
+ ''
+ BoxBackgroundColor transparent
+ BoxBorderColor $GRAY
+ BoxFontColor $DARK
+ ''
+ DelayFontColor $DARK
+ ''
+ LifeLineBorderColor $PRIMARY_DARK
+ LifeLineBorderThickness 2
+ LifeLineBackgroundColor $PRIMARY_LIGHT
+ ''
+ GroupBorderColor $GRAY
+ GroupFontColor $DARK
+ GroupHeaderFontColor $INFO
+ ''
+ DividerBackgroundColor $WHITE-$LIGHT
+ DividerBorderColor $GRAY
+ DividerBorderThickness 2
+ DividerFontColor $DARK
+ ''
+ ReferenceBackgroundColor transparent
+ ReferenceBorderColor $GRAY
+ ReferenceFontColor $DARK
+ ReferenceHeaderFontColor $INFO
+ ''
+ StereotypeFontColor $PRIMARY_TEXT
+ ''
+ ParticipantBorderThickness 0
+ GroupBodyBackgroundColor transparent
+}
+!endsub
+
+!startsub partition
+
+skinparam partition {
+ BorderColor $PRIMARY
+ FontColor $PRIMARY
+ BackgroundColor transparent
+}
+!endsub
+
+!startsub collections
+
+skinparam collections {
+ $primary_scheme()
+}
+!endsub
+
+!startsub control
+
+skinparam control {
+ $primary_scheme()
+ FontColor $DARK
+}
+!endsub
+
+!startsub entity
+
+skinparam entity {
+ $primary_scheme()
+ FontColor $DARK
+}
+!endsub
+
+!startsub boundary
+
+skinparam boundary {
+ $primary_scheme()
+ FontColor $DARK
+}
+!endsub
+
+!startsub agent
+
+skinparam agent {
+ $primary_scheme()
+ FontColor $DARK
+}
+!endsub
+
+!startsub note
+
+skinparam note {
+ BorderThickness 1
+ BackgroundColor $INFO_LIGHT-$INFO
+ BorderColor $INFO
+ FontColor %darken($SCORE, 40)
+}
+!endsub
+
+!startsub artifact
+
+skinparam artifact {
+ $primary_scheme()
+}
+!endsub
+
+!startsub component
+
+skinparam component {
+ $primary_scheme()
+}
+!endsub
+
+!startsub interface
+
+skinparam interface {
+ BackgroundColor $DANGER_LIGHT
+ BorderColor $DANGER
+ FontColor $DARK
+}
+!endsub
+
+!startsub storage
+
+skinparam storage {
+ $primary_scheme()
+ FontColor $DARK
+}
+!endsub
+
+!startsub node
+
+skinparam node {
+ BackgroundColor $SECONDARY_LIGHT-$SECONDARY
+ BorderColor $PRIMARY
+ FontColor $DARK
+}
+!endsub
+
+!startsub cloud
+
+skinparam cloud {
+ BackgroundColor transparent
+ BorderColor $PRIMARY
+ FontColor $DARK
+}
+!endsub
+
+!startsub database
+
+skinparam database {
+ $primary_scheme()
+ FontColor $DARK
+}
+!endsub
+
+!startsub class
+
+skinparam class {
+ $primary_scheme()
+ HeaderBackgroundColor $PRIMARY-$PRIMARY_DARK
+ StereotypeFontColor $DARK
+ BorderThickness 1
+ AttributeFontColor $LIGHT
+ AttributeFontSize 11
+}
+!endsub
+
+!startsub object
+
+skinparam object {
+ $primary_scheme()
+ StereotypeFontColor $DARK
+ BorderThickness 1
+ AttributeFontColor $SECONDARY_TEXT
+ AttributeFontSize 11
+}
+!endsub
+
+!startsub usecase
+
+skinparam usecase {
+ $primary_scheme()
+ BorderThickness 2
+ StereotypeFontColor $PRIMARY
+}
+!endsub
+
+!startsub rectangle
+
+skinparam rectangle {
+ FontColor $PRIMARY
+ BackgroundColor $SECONDARY_LIGHT-$SECONDARY
+ BorderThickness 2
+ StereotypeFontColor $PRIMARY
+}
+!endsub
+
+!startsub package
+
+skinparam package {
+ $primary_scheme()
+ BackgroundColor $SECONDARY_LIGHT-$SECONDARY
+ BorderThickness 2
+}
+!endsub
+
+!startsub folder
+
+skinparam folder {
+ BackgroundColor $WHITE-$SECONDARY_LIGHT
+ BorderColor $PRIMARY
+ FontColor $PRIMARY
+ BorderThickness 2
+}
+!endsub
+
+!startsub frame
+
+skinparam frame {
+ BackgroundColor $WHITE-$SECONDARY_LIGHT
+ BorderColor $INFO
+ FontColor $INFO
+ BorderThickness 2
+}
+!endsub
+
+!startsub state
+
+skinparam state {
+ $primary_scheme()
+ BorderColor $PRIMARY_DARK
+ StartColor $INFO
+ EndColor $INFO
+ AttributeFontColor $SECONDARY_TEXT
+ AttributeFontSize 11
+}
+!endsub
+
+!startsub queue
+
+skinparam queue {
+ $primary_scheme()
+}
+!endsub
+
+!startsub card
+
+skinparam card {
+ BackgroundColor $INFO_LIGHT-$INFO
+ BorderColor $INFO
+ FontColor $INFO_TEXT
+}
+!endsub
+
+!startsub file
+
+skinparam file {
+ BackgroundColor $SECONDARY_LIGHT-$SECONDARY
+ BorderColor $GRAY
+ FontColor $GRAY
+
+}
+!endsub
+
+!startsub stack
+
+skinparam stack {
+ $primary_scheme()
+}
+!endsub
diff --git a/docs/features/communication/some_ip_gateway/assets/some_ip_gateway_architecture.drawio.svg b/docs/features/communication/some_ip_gateway/assets/some_ip_gateway_architecture.drawio.svg
new file mode 100644
index 00000000000..5c110a038a3
--- /dev/null
+++ b/docs/features/communication/some_ip_gateway/assets/some_ip_gateway_architecture.drawio.svg
@@ -0,0 +1,439 @@
+
diff --git a/docs/features/communication/some_ip_gateway/assets/some_ip_gateway_details.drawio.svg b/docs/features/communication/some_ip_gateway/assets/some_ip_gateway_details.drawio.svg
new file mode 100644
index 00000000000..699817d6a9b
--- /dev/null
+++ b/docs/features/communication/some_ip_gateway/assets/some_ip_gateway_details.drawio.svg
@@ -0,0 +1,552 @@
+
diff --git a/docs/features/communication/some_ip_gateway/index.rst b/docs/features/communication/some_ip_gateway/index.rst
new file mode 100644
index 00000000000..5d3b6f85070
--- /dev/null
+++ b/docs/features/communication/some_ip_gateway/index.rst
@@ -0,0 +1,249 @@
+..
+ # *******************************************************************************
+ # Copyright (c) 2024 Contributors to the Eclipse Foundation
+ #
+ # See the NOTICE file(s) distributed with this work for additional
+ # information regarding copyright ownership.
+ #
+ # This program and the accompanying materials are made available under the
+ # terms of the Apache License Version 2.0 which is available at
+ # https://www.apache.org/licenses/LICENSE-2.0
+ #
+ # SPDX-License-Identifier: Apache-2.0
+ # *******************************************************************************
+
+ # #914 Feature Request for SOME/IP Gateway
+
+.. _some_ip_gateway_feature:
+
+SOME/IP-Gateway
+###########################
+
+.. document:: SOME_IP-Gateway
+ :id: doc__some_ip_gateway
+ :status: valid
+ :safety: ASIL_B
+ :tags: contribution_request, feature_request
+
+
+.. toctree::
+ :hidden:
+
+ architecture/index.rst
+ requirements/index.rst
+ service_discovery/index.rst
+
+
+Feature flag
+============
+
+To activate this feature, use the following feature flag:
+
+``experimental_some-ip-gateway``
+
+Abstract
+========
+
+This contribution describes how data-exchange that is outside the scope of internal communication (IPC) shall be handled in modules that service data-input and data-output to a platform.
+Services handling data in this context can be considered as gateways.
+The focus is on a gateway to handle SOME/IP communication with external devices or counterparts, therefore this feature request is called: SOME/IP-Gateway
+
+This feature request includes:
+ - A description of how a SOME/IP gateway service (or data broker) shall be implemented
+ - How the SOME/IP gateway services shall integrate with the zero-copy communication from IPC
+ - How data shall be mapped or translated between SOME/IP protocol and IPC communication
+ - How service discovery should be integrated, also for services that are offered by IPC-Clients
+ - How End-to-End protection and checking shall be realized
+
+.. _Motivation:
+
+Motivation
+==========
+
+S-CORE is targeting high-performance automotive systems with safety impact. Applications integrated on S-CORE will be distributed across multiple processes and frameworks (like FEO)
+that schedule software components (i.e. activities) with the need to exchange data.
+For data-exchange between applications the IPC feature is providing high-speed communication capabilities, but when it comes to communication with applications outside the scope of
+the S-CORE platform, services are required that will handle protocols for communication with both side. This is for instance the case when communication with rest of vehicle or sensors
+needs to be realized with the SOME/IP protocol.
+
+For software component developers it should be unrecognized that data is originated from a SOME/IP communication channel, the data should be provided with the same API as in IPC.
+Nonetheless integrators and architects will have to configure the system to receive or send data over SOME/IP.
+
+
+.. _Rationale:
+
+Rationale
+==========
+
+SOME/IP and IPC use different mechanisms and data representations to communicate. Therefor it's not only a task of this gateway
+to adapt the communication, but also to transform from one representation to another. This includes changing data layout, filling in missing data, filtering traffic, error handling, service discovery and further steps.
+
+Hence the gateway shall be a transparent bridge between IPC and SOME/IP. On the one side it should act as a participant in IPC and fulfill all requirements to this accordingly, where providing data or consuming it.
+Whereas on the other side it shall participate in SOME/IP communication acting as a SOME/IP service and client fulfilling all SOME/IP requirements and defined communication.
+Between these two contexts developers shall be able to create signal or data mappings and translate the different data-types and representations of the two contexts.
+
+
+This module shall fulfill the following requirements:
+ - Multi-Binding support - :need:`feat_req__com__multi_binding_support`
+ - binding agnostic API - :need:`feat_req__com__binding_agnostic_api`
+ - deployment configuration - :need:`feat_req__com__multi_binding_depl`
+
+
+.. _Specification:
+
+Specification
+=============
+
+The requirements from Communication generally apply to the SOME/IP Gateway.
+
+
+SOME/IP protocol implementation
+-------------------------------
+
+The protocol implementation shall be fully compatible and complying with the SOME/IP specification from AUTOSAR Adaptive. (:need:`feat_req__some_ip_gateway__someip_protocol`)
+Specifically the SOME/IP specification from AUTOSAR release R24-11 shall be supported by the SOME/IP Gateway. This shall guarantee that systems integrated with the SOME/IP gateway can be used in according
+automotive E/E-architectures.
+Protocol implementations shall be wrapped in an abstraction API, that stays stable and allows implementations may be exchanged, potentially even by binary only libraries.
+
+The SOME/IP Gateway shall support SOME/IP Events, Fields and Methods and shall map these accordingly into IPC.
+
+The SOME/IP Gateway shall support SOME/IP Service Discovery. Please refer to the Service Discovery page for detailed discussions on how SD shall be realized with IPC-Clients.
+
+..
+ # fix #1424 SOME/IP Gateway in lifecycle-management
+
+SOME/IP Gateway processes and life cycle management
+---------------------------------------------------
+
+The implementation of a gateway likely requires using one or multiple processes. Startup of processes for the gateway, as with any other
+process in the S-CORE system, need to be put under the control of lifecycle-management (see feature Lifecycle).
+Hence the SOME/IP Gateway must not start any processes on its own, but configure the lifecycle launch and health-monitoring accordingly.
+Specifically for the integration of the SOME/IP Stack "plug-in", which is expected to be QM, whereas the rest of the gateway is ASIL-B,
+if one or more additional processes need to be spawned and additional executables need to be involved with the implementation,
+all need to go into launch control in health monitoring and must not be setup (fork()) by the gateway.
+
+
+
+SOME/IP Gateway Security Goals
+------------------------------
+
+The security approach for SOME/IP gateway shall achieve the following security goals:
+
+- access control (:need:`feat_req__com__acl_per_service_instance`)
+
+The SOME/IP Gateway service instance shall be defined in the deployment configuration.
+
+- :need:`ACL Placement `
+
+
+Backwards Compatibility
+=======================
+
+As there is currently no previous solution for gateways in S-CORE, no backwards compatibility is required.
+Subsequent changes to the SOME/IP gateway module shall keep the API stable where possible and introduce breaking APIs only with approval from tech lead circle.
+Applications shall stay stable on API layer, need to recompile is acceptable.
+
+Security Impact
+===============
+
+Be aware, communication with SOME/IP generally is considered to be not secure. Integrators may apply measures that are outside the
+scope of the SOME/IP gateway to secure the communication (IPsec, MACsec, ...).
+
+.. note::
+ it is expected that a feature request for crypto and security will cover the necessary measures.
+ `Feature Request for Security & Crypto `_
+
+
+Access Control List (ACL)
+-------------------------
+
+The gateway shall only forward selective service instances originating from IP addresses configured in an allow-list.
+The logic required for this is protocol specific and therefore part of this feature request.
+
+Be aware that an additional security mechanism may be necessary that ensures that IP addresses are not forged. This mechanism is out of scope of this feature.
+
+An access control mechanism is part of a firewall solution, which states that only the traffic defined in the security policy is allowed onto the network and all other traffic must be silently dropped.
+Access Control acts on OSI Layer 5-7. It shall fulfill the following:
+
+- What SOME/IP service instances to forward
+- What IP address is allowed to offer a SOME/IP service instance
+- Configuration of ACL is done at deployment
+- Versioning of services
+- ACL, or single parameters of it, shall be able to be switched on/off
+- It shall be possible to persistently log ACL drop actions
+
+.. note::
+ - Checking SOME/IP-SD messages with the ACL is optional because no functional data is transported.
+ - SOME/IP-SD messages are not protected as per AUTOSAR Adaptive specification.
+
+
+.. uml::
+ :name: doc__acl_activity_diagram
+ :scale: 80
+ :align: center
+ :caption: Simplified Access Control Activity Diagram
+
+ !include assets/puml-theme-score.puml
+
+ start
+
+ :Ingress SOME/IP;
+ :ACL Check;
+
+ if (Packet matches ACL entry?) then (Yes)
+ :Process Packet;
+ else (No)
+ :Log Event;
+ if (ACL is active?) then (Yes)
+ :Drop Packet;
+ else (No)
+ :Process Packet;
+ endif
+ endif
+
+ stop
+
+
+Safety Impact
+=============
+
+SOME/IP stack and underlying OS network stacks are typically QM only. Freedom from interference needs to be respected between the
+safety classified IPC component (mw::com) and the SOME/IP stack which is part of the gateway. The SOME/IP communication itself needs
+to be properly protected by E2E to maintain a safe communication via the grey SOME/IP channel.
+
+End-to-End (E2E) protection with CRC and counters
+-------------------------------------------------
+
+Applications communicating over the network may have to protect data with end-to-end protection (E2E), which may involve
+CRC-protection and checks, and message counters.
+
+There are several E2E (= End-to-End) profiles, which utilize various CRC routines as part of AUTOSAR E2E Protocol Specification, that shall be supported with the SOME/IP Gateway.
+
+Though the implementation of the SOME/IP protocol itself is likely not going to be ASIL-B compliant and have a safety consideration of QM rather,
+E2E-checks and protection need to happen in an ASIL-B context. The gateway may perform the CRC routines as a central service.
+All communication channels (IPC) to this central service must be qualified for ASIL-B, and protected against data loss / loss of samples.
+
+SOME/IP Events, Methods, and Fields need to be supported with E2E protection.
+
+Please refer to the SOME/IP Gateway architecture for further details.
+
+References
+
+- `AUTOSAR_FO_PRS_E2EProtocol `_
+- `AUTOSAR_FO_RS_E2E `_
+
+License Impact
+==============
+
+[How could the copyright impacted by the license of the new contribution?]
+
+Since SOME/IP is a protocol, including applied E2E protection and the according profile (polynom, etc.),
+defined by AUTOSAR and published under the license of AUTOSAR, the gateway implementation shall carefully distinguish between the SOME/IP communication stack,
+the E2E protection of data, and the integration into S-CORE mw::com. Breach of foreign licenses must be avoided.
+
+Anybody using SOME/IP Gateway needs to make sure to follow the license conditions and rules of AUTOSAR.
+
+How to Teach This
+=================
+
+TBD
diff --git a/docs/features/communication/some_ip_gateway/requirements/index.rst b/docs/features/communication/some_ip_gateway/requirements/index.rst
new file mode 100644
index 00000000000..bc26141f5f7
--- /dev/null
+++ b/docs/features/communication/some_ip_gateway/requirements/index.rst
@@ -0,0 +1,77 @@
+..
+ # *******************************************************************************
+ # Copyright (c) 2024 Contributors to the Eclipse Foundation
+ #
+ # See the NOTICE file(s) distributed with this work for additional
+ # information regarding copyright ownership.
+ #
+ # This program and the accompanying materials are made available under the
+ # terms of the Apache License Version 2.0 which is available at
+ # https://www.apache.org/licenses/LICENSE-2.0
+ #
+ # SPDX-License-Identifier: Apache-2.0
+ # *******************************************************************************
+
+SOME/IP Gateway Requirements
+############################
+
+
+Functional Requirements
+=======================
+
+.. feat_req:: Plug-In-IFC for SOME/IP protocol stacks
+ :id: feat_req__some_ip_gateway__stack_plugin_ifc
+ :reqtype: Functional
+ :security: NO
+ :safety: QM
+ :satisfies: stkh_req__communication__extensible_external, stkh_req__communication__supported_net
+ :status: valid
+
+ The SOME/IP Gateway shall support an interface to plug-in a SOME/IP stack implementation.
+
+.. feat_req:: Plug-In-IFC for End-to-End protection modules
+ :id: feat_req__some_ip_gateway__e2e_plugin_ifc
+ :reqtype: Functional
+ :security: NO
+ :safety: ASIL_B
+ :satisfies: stkh_req__communication__safe
+ :status: valid
+
+ The SOME/IP Gateway shall support an interface to plug-in a E2E protection service implementation.
+
+.. feat_req:: Compatibility with AUTOSAR SOME/IP Protocol Specification
+ :id: feat_req__some_ip_gateway__someip_protocol
+ :reqtype: Functional
+ :security: NO
+ :safety: ASIL_B
+ :satisfies: stkh_req__communication__supported_net
+ :status: valid
+
+ The SOME/IP protocol implementation shall be fully compatible and complying with the SOME/IP protocol specification from AUTOSAR Adaptive Version 24-11.
+ - `AUTOSAR_FO_PRS_SOMEIPProtocol `_
+ - `AUTOSAR_FO_RS_SOMEIPProtocol `_
+
+.. feat_req:: Compatibility with AUTOSAR E2E Protocol Specification
+ :id: feat_req__some_ip_gateway__e2e_specs
+ :reqtype: Functional
+ :security: NO
+ :safety: ASIL_B
+ :satisfies: stkh_req__communication__supported_net
+ :status: valid
+
+ The E2E protection implementation shall be fully compatible and complying with the E2E protocol specification from AUTOSAR Adaptive Version 24-11.
+ - `AUTOSAR_FO_PRS_E2EProtocol `_
+ - `AUTOSAR_FO_RS_E2E `_
+
+
+.. feat_req:: Compatibility with AUTOSAR SOME/IP Service Discovery Protocol Specification
+ :id: feat_req__some_ip_gateway__someip_sd_protocol
+ :reqtype: Functional
+ :security: NO
+ :safety: ASIL_B
+ :satisfies: stkh_req__communication__supported_net
+ :status: valid
+
+ The Service Discovery implementation shall be fully compatible and complying with the SOME/IP service discovery specification from AUTOSAR Adaptive Version 24-11.
+ - `AUTOSAR_FO_PRS_SOMEIPServiceDiscoveryProtocol `_
+ - `AUTOSAR_FO_RS_SOMEIPServiceDiscoveryProtocol `_
diff --git a/docs/features/communication/some_ip_gateway/service_discovery/index.rst b/docs/features/communication/some_ip_gateway/service_discovery/index.rst
new file mode 100644
index 00000000000..cee8f4ac6db
--- /dev/null
+++ b/docs/features/communication/some_ip_gateway/service_discovery/index.rst
@@ -0,0 +1,182 @@
+..
+ # *******************************************************************************
+ # Copyright (c) 2025 Contributors to the Eclipse Foundation
+ #
+ # See the NOTICE file(s) distributed with this work for additional
+ # information regarding copyright ownership.
+ #
+ # This program and the accompanying materials are made available under the
+ # terms of the Apache License Version 2.0 which is available at
+ # https://www.apache.org/licenses/LICENSE-2.0
+ #
+ # SPDX-License-Identifier: Apache-2.0
+ # *******************************************************************************
+
+.. _some_ip_gateway_service_discovery:
+
+SOME/IP Gateway Service Discovery
+#################################
+
+The implementation shall be fully compatible and complying with the SOME/IP Service Discovery Protocol specification from AUTOSAR Adaptive.
+Service discovery deals with discovery and connection setup of services.
+The basic summary of service discovery is as follows:
+
+- provided / required services (including their service elements like events, methods, and fields) must be configured
+- (locally) provided services are discovered (locally) via IPC and then offered on the network by sending a SOME/IP-SD message with an OfferService entry according to configuration
+- (locally) required services trigger the discovery on the network by sending of a SOME/IP-SD message with a FindService entry
+- when a SOME/IP-SD message containing a FindService entry is received, the SOME/IP gateway checks this service has been already offered locally via IPC
+- the IPC service discovery is used by the SOME/IP gateway and no parallel discovery mechanism is introduced
+
+Configuration
+=============
+
+The configuration tells the SOME/IP communication stack which services it should provide and which services it should require on the network.
+The configuration contains SOME/IP and SOME/IP-SD settings as well as IP interface bindings.
+Events, methods and fields are configured as well.
+Only full interfaces of services are forwarded (all events, methods, fields of a service).
+
+The integrator must be able to change configuration at runtime deployment.
+Thus it is likely read from one or multiple files.
+
+Provided services
+=================
+
+Services available in the local ECU / VM are offered by the SOME/IP gateway once they become internally available and are present in the configuration.
+This is done by sending an SOME/IP-SD messages containing an OfferService entry to the network.
+As long as the service is locally available the service offering is periodically (according to the configuration) renewed by sending a SOME/IP-SD messages containing an OfferService entry to the network.
+
+.. uml::
+ :alt: Gateway offers a service to the network
+
+ @startuml
+ participant "Producer" as IPC_client
+ participant "Service\nvia IPC" as Service
+ participant "SOME/IP Gateway" as Someipgateway
+ actor "Network" as Network
+
+ IPC_client -> Service ** : create()
+ IPC_client -> Service : OfferService()
+ Someipgateway -> Service: service_discovery()
+ Someipgateway -> Network: OfferService
+ Network -> Someipgateway: SubscribeEventgroup
+ Someipgateway -> Someipgateway: create_proxy()
+ @enduml
+
+Once the service ceased to exist locally, the SOME/IP communication stack sends a SOME/IP-SD message containing a StopOfferService entry to the network.
+
+.. uml::
+ :alt: Gateway stops service offer
+
+ @startuml
+ participant "Producer" as IPC_client
+ participant "Service\nvia IPC" as Service
+ participant "SOME/IP Gateway" as Someipgateway
+ actor "Network" as Network
+
+ IPC_client -> Service : StopOfferService()
+ Someipgateway -> Service: service_discovery()
+ Someipgateway -> Network: StopOfferService
+ @enduml
+
+.. note:: ``mw::com::::StartFindService()`` function can tell us that a service is offered or stopped. But using it is awkward / complicated.
+
+Required services
+=================
+
+For configured required services, the SOME/IP communication stack will send a SOME/IP-SD message containing a FindService entry to the network.
+
+FindService message might not be needed, if OfferService messages for that services have been already received.
+
+Upon initial reception of a SOME/IP-SD message containing an OfferService entry, the SOME/IP communication stack checks if the service has been configured as required service.
+If so, the SOME/IP communication stack offers the service locally in the ECU / VM.
+Here, initial reception is the first reception after a previous service loss or withdrawal, i.e.,
+
+- after the reception of a SOME/IP-SD message containing an StopOfferService entry
+- after a TTL expiry of the previous OfferService entry
+- after the detection of a reboot of the (remote) service provider
+- after a link-down/link-up event
+
+.. uml::
+ :alt: Gateway receives OfferService from the network
+
+ @startuml
+ actor "Network" as Network
+ participant "SOME/IP Gateway" as Someipgateway
+ participant "Service\nvia IPC" as Service
+ participant "Consumer" as IPC_client
+
+ Network -> Someipgateway: OfferService
+ Someipgateway -> Service ** : create()
+ Someipgateway -> Service: OfferService()
+ IPC_client -> Service: service_discovery()
+ IPC_client -> Service: connect()
+ @enduml
+
+.. note::
+ The SOME/IP communication stack can create the service before receiving an OfferService,
+ but can only start offering it after having received an OfferService message from the network.
+ This behavior may reduce the time until the service is available for consumers, but may increase boot time.
+ Thus the decision is to create the service only after having received an OfferService message from the network.
+
+Upon reception of SOME/IP-SD message containing an StopOfferService entry, the SOME/IP communication stack stops the service offered via IPC as well.
+
+.. uml::
+ :alt: Gateway receives StopOfferService from the network
+
+ @startuml
+ actor "Network" as Network
+ participant "SOME/IP Gateway" as Someipgateway
+ participant "Service\nvia IPC" as Service
+ participant "Consumer" as IPC_client
+
+ Network -> Someipgateway: StopOfferService
+ Someipgateway -> Service: StopOfferService()
+ IPC_client -> Service: service_discovery()
+ IPC_client -> IPC_client: handle_disconnect()
+ @enduml
+
+.. note::
+ If the service times out we may internally stop the service, but keep it alive until another timeout is reached.
+ The intention is to avoid destroying and recreating the service repeatedly.
+
+ TODO: is this optimization for a rare case and worth the complexity?
+
+FindService
+================
+
+Upon reception of a SOME/IP-SD message containing a FindService entry, the SOME/IP communication stack checks if the service is available locally and has been configured as provided service.
+If both questions are answered positively, the SOME/IP communication stack responds by sending a SOME/IP-SD message containing an OfferService to the sender of the SOME/IP-SD message containing a FindService entry.
+
+This will **not** trigger creation of the service internally by any means.
+Only lookup of running services is done.
+
+.. uml::
+ :alt: Gateway receives FindService from the network
+
+ @startuml
+ actor "Network" as Network
+ participant "SOME/IP Gateway" as Someipgateway
+ participant "Service\nvia IPC" as Service
+
+ Network -> Someipgateway: FindService
+ Someipgateway -> Service: service_discovery()
+ alt Service available
+ Someipgateway -> Network: OfferService
+ end
+ @enduml
+
+If a service is configured to be needed and no OfferService has been received yet, the SOME/IP communication stack shall send a SOME/IP-SD message containing a FindService entry.
+
+.. uml::
+ :alt: Gateway sends FindService to the network
+
+ @startuml
+ actor "Network" as Network
+ participant "SOME/IP Gateway" as Someipgateway
+
+ loop required Service
+ alt no OfferService received
+ Someipgateway -> Network: FindService
+ end
+ end
+ @enduml