[Year 12 SofDev] Physical Layer
malcolm
mjarb at iname.com
Thu Mar 10 21:16:19 EST 2011
Hi Russell,
Thanks for your comments, its opened up an interesting discussion point.
" According to wiki, the physical layer is much more than a pipe:"
I Still have my reservations regarding the validity of some wiki sites, I
don't know which one your referring to, I would rather refer to the issued
standards which can be found available on the net.
Most of the X Series protocols which relate to Data Networks are available
for reference at this site:
http://www.itu.int/itu-t/recommendations/index.aspx?ser=X
If you refer to ITU-T Recommendation X.200 - Information Technology - Open
Systems Interconnection - Basic reference Model as issued by the ITU
(http://www.itu.int/rec/T-REC-X.200-199407-I/en ) Released in 1994.
Section 7 - Detailed description of the resulting OSI architecture
7.7 - Physical layer
The Physical Layer provides the mechanical, electrical, functional and
procedural means to activate, maintain, and
de-activate physical-connections for bit transmission between
data-link-entities.
A physical-connection may involveintermediate open systems, each relaying
bit transmission within the Physical Layer.
Physical Layer entities are interconnected by means of a physical medium.
A data-circuit is a communication path in the physical media for OSI among
two or more physical-entities,
together with the facilities necessary in the Physical Layer for the
transmission of bits on it.
Physical-connection activation and deactivation
These functions provide for the activation and deactivation of
physical-connections between two data-link-entities upon
request from the Data Link Layer.
Annex A -
2.1 - It is essential that the architecture permits usage of a realistic
variety of physical media for interconnection
with different control procedures (for example ITU-T Recs. V.24, V.25,
etc.). Application of principles in 6.2 c), e)
and h) leads to identification of a Physical Layer as the lowest layer in
the architecture.
2.2 - Some physical communication media (for example, telephone line)
require specific techniques to be used in
order to transmit data between systems despite a relatively high error rate
(i.e. an error rate not acceptable for the great
majority of applications). These specific techniques are used in data-link
control procedures which have been studied
and standardized for a number of years. It must also be recognized that new
physical communication media (for
example, fibre optics) will require different data-link control procedures.
Application of principles in 6.2 c), e) and h)
leads to identification of a Data Link Layer on top of the Physical Layer in
the architecture.
I have just pulled out a few lines from the recommendation.
I am still of the opinion that the Physical layer is just a pipe over
which the data circuit is connected (via interface cards, etc) and
controlled by the next layer above - as in the data link level.
The other X series recommendations such as X20-89 (typically modems X21,
Packet switching equipment X25/32/50/75) deal with how devices interface to
the physical layer and how they handle communications over the physical
layer and failures at physical and link levels.
An alternate viewpoint maybe. Anyone else have a view on this.
Regards
Malcolm Carson
Glenmore Park High, NSW
-----Original Message-----
From: sofdev-bounces at edulists.com.au [mailto:sofdev-bounces at edulists.com.au]
On Behalf Of Russell Quinn
Sent: Thursday, 10 March 2011 12:55 PM
To: sofdev at edulists.com.au
Subject: Re: [Year 12 SofDev] Physical Layer
According to wiki, the physical layer is much more than a pipe:
"
The major functions and services performed by the Physical Layer are:
Bit-by-bit or symbol-by-symbol delivery
Providing a standardized interface to physical transmission media, including
Mechanical specification of electrical connectors and cables, for example
maximum cable length Electrical specification of transmission line signal
level and impedance Radio interface, including electromagnetic spectrum
frequency allocation and specification of signal strength, analog bandwidth,
etc.
Specifications for IR over optical fiber or a wireless IR communication link
Modulation Line coding Bit synchronization in synchronous serial
communication Start-stop signalling and flow control in asynchronous serial
communication Circuit switching Multiplexing Establishment and termination
of circuit switched connections Carrier sense and collision detection
utilized by some level 2 multiple access protocols Equalization filtering,
training sequences, pulse shaping and other signal processing of physical
signals Forward error correction[2] for example bitwise convolutional coding
Bit-interleaving and other channel coding The Physical Layer is also
concerned with Bit rate Point-to-point, multipoint or point-to-multipoint
line configuration Physical network topology, for example bus, ring, mesh or
star network Serial or parallel communication Simplex, half duplex or full
duplex transmission mode Autonegotiation "
Regards,
Russell Quinn
________________________________________
From: sofdev-bounces at edulists.com.au [sofdev-bounces at edulists.com.au] On
Behalf Of sofdev-request at edulists.com.au [sofdev-request at edulists.com.au]
Sent: Thursday, 10 March 2011 9:31 AM
To: sofdev at edulists.com.au
Subject: sofdev Digest, Vol 72, Issue 28
Send sofdev mailing list submissions to
sofdev at edulists.com.au
To subscribe or unsubscribe via the World Wide Web, visit
http://www.edulists.com.au/mailman/listinfo/sofdev
or, via email, send a message with subject or body 'help' to
sofdev-request at edulists.com.au
You can reach the person managing the list at
sofdev-owner at edulists.com.au
When replying, please edit your Subject line so it is more specific than
"Re: Contents of sofdev digest..."
Today's Topics:
1. Re: SD key knowledge (Andrew Shortell)
2. Re: SD key knowledge (malcolm)
3. Re: SD key knowledge (Mark KELLY)
4. UCD do have relevance .... (Bell, Kenneth C)
----------------------------------------------------------------------
Message: 1
Date: Wed, 09 Mar 2011 20:18:23 +1100
From: Andrew Shortell <shortell at get2me.net>
Subject: Re: [Year 12 SofDev] SD key knowledge
To: "Year 12 Software Development Teachers' Mailing List"
<sofdev at edulists.com.au>
Message-ID: <C99D910F.3A41%shortell at get2me.net>
Content-Type: text/plain; charset="iso-8859-1"
Hi Mark
[nice ppt btw]
Each and EVERY member of the study design panel should be able to clearly
and unequivocally, definitively answer your question because they put it in
the study design. It did not get there by accident. All members of the panel
are responsible for the document...
Members of the panel discuss (and read) the document and have the
opportunity to clarify anything that they do not understand.
Just occasionally something gets missed ... That is why we have errata and
corrections published (and I know all about those!)
If it is not an errata the there must be a definitive answer so let?s just
ask the panel to provide it rather than us guessing, perhaps not getting it
in the way that the panel intended and absolutely missing what the exam
setting panel might think. We do NOT want the exam setting panel to receive
a torrent of unwarranted adverse comments.
As mature sensible professionals we should all be working towards a common
set of understandings that are generously shared (as per this list).
[btw ? at least a dead dog does not fight you when you stick the cotton bud
in to its ears! Try doing an alive Alaskan malamute! ]
Andrew
--
Andrew Shortell
Heidelberg Teaching Unit
Ph 9470 3403
Fax 9470 3215
c/o Reservoir High School
855 Plenty Rd
Reservoir 3073
On 9/03/11 1:21 PM, "Mark KELLY" <kel at mckinnonsc.vic.edu.au> wrote:
> SD U3O1 KK04
> Purposes and functions of the physical layer (Layer 1) of the OSI and
> the relationship of the physical layer to the Transmission Control
> Protocol/Internet Protocol model
>
> For quite some time now I've been avoiding this KK because I'd rather
> clean a dead dog's ears than spend time on the OSI.
>
> But in the end I had to find the cotton buds and get stuck in, and I
> think I have a reasonable overview of the OSI and how TCP/IP maps to
> it.? (even produced a draft slideshow
<http://www.vceit.com/slideshows/SD-OSI.ppt> ).
>
> But the second part of KK04 really has me baffled: the relationship of
> the physical layer to the Transmission Control Protocol/Internet Protocol
model.
> I know that TCP/IP's Network interface layer maps to OSI's physical
> layer (and the data link layer), but for the life of me I can't see
> how it's any more significant than any of OSI's or TCP/IP's other layers.
>
> Can someone suggest why the relationship between the OSI physical
> layer and TCP/IP is so significant??
> Has this relationship been in the papers?? Has this physical
> relationship resulted in offspring?
> Is Mr OSI going to be on Oprah... or the Jerry Springer show?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.edulists.com.au/pipermail/sofdev/attachments/20110309/269b9f55/at
tachment-0001.html
------------------------------
Message: 2
Date: Wed, 9 Mar 2011 21:42:01 +1100
From: "malcolm" <mjarb at iname.com>
Subject: Re: [Year 12 SofDev] SD key knowledge
To: "'Year 12 Software Development Teachers' Mailing List'"
<sofdev at edulists.com.au>
Message-ID:
<!&!AAAAAAAAAAAYAAAAAAAAAGPyxeBNO0ZNiMTNYNVfeQuijQAAEAAAAHIOE31DkNhHrDR83BHj
4fQBAAAAAA==@iname.com>
Content-Type: text/plain; charset="us-ascii"
Hi,
Just adding to the conversation,
The physical layer is just that - the actual cable, whether cat 5 or other.
As you progress up the layers, the data link layer is your protocols for
your network card to get the signals on and off the cable and the next layer
up (the network layer) is where the data gets formed into packets and
addressed - logical address/Mac address.
After that the transport layer is where the data gets chunked for
transmission or reassembled on reception into a data stream.
Most people talk about TCP/IP as if they were together yet they each
represent a different layer in the OSI model. TCP being in one layer and IP
in the other.
The only reason I see them as being important is that they flow down from
the above layers to allow the data stream to be broken down into packets,
addressed, etc so they can go out on the cable or visa versa.
Each layer is as important as the one above or below. If one layer doesn't
function correctly then the data can be lost or not sent/received/corrupted,
etc.
We can use different tests to test the layers in a network - ping as an
example - ping a domain name - www.microsoft.com, ping localhost, or ping a
specific ip address on a network to check that different layers e.g link,
etc are working correctly.
This link may be of useful reference http://tools.ietf.org/html/rfc1122
Regards
Malcolm Carson
Glenmore Park High School, NSW
-----Original Message-----
From: sofdev-bounces at edulists.com.au [mailto:sofdev-bounces at edulists.com.au]
On Behalf Of David Dawson
Sent: Wednesday, 9 March 2011 1:37 PM
To: sofdev at edulists.com.au
Subject: Re: [Year 12 SofDev] SD key knowledge
My guess is that it means the 'physical layer' relates to 'network
standards' in Hardware, like the electronics and microtechnology in modems
and network cards, SIMS etc; connections like CAT 5 and 802.11 wireless
transmission - which then must send packets via a standard communication
protocol (TCP/IP) for transmission of data across the Internet and LANs.
Hence this relationship points to a universal standard for Internet
connection devices.
Let me know if I am warm .....
David Dawson
Head of Information Technology Learning Area Head of Learning Technologies
St Kilda Rd Campus Wesley College
577 St Kilda Rd
Melbourne 3004
Ph 8102 6340
Mob 0425 718147
>>> sofdev-bounces at edulists.com.au 03/09/11 1:21 PM >>>
SD U3O1 KK04
Purposes and functions of the physical layer (Layer 1) of the OSI and the
relationship of the physical layer to the Transmission Control
Protocol/Internet Protocol model
For quite some time now I've been avoiding this KK because I'd rather clean
a dead dog's ears than spend time on the OSI.
But in the end I had to find the cotton buds and get stuck in, and I think I
have a reasonable overview of the OSI and how TCP/IP maps to it.
(even produced a draft slideshow).
But the second part of KK04 really has me baffled: the relationship of the
physical layer to the Transmission Control Protocol/Internet Protocol model.
I know that TCP/IP's Network interface layer maps to OSI's physical layer
(and the data link layer), but for the life of me I can't see how it's any
more significant than any of OSI's or TCP/IP's other layers.
Can someone suggest why the relationship between the OSI physical layer and
TCP/IP is so significant?
Has this relationship been in the papers? Has this physical relationship
resulted in offspring?
Is Mr OSI going to be on Oprah... or the Jerry Springer show?
--
Mark Kelly
Manager of ICT, Reporting, IT Learning Area McKinnon Secondary College
McKinnon Rd McKinnon 3204, Victoria, Australia Direct line / Voicemail: +613
8520 9085, Fax +613 9578 9253 kel at mckinnonsc.vic.edu.au
VCE IT Lecture Notes: http://vceit.com
Moderator: IT Applications Edulist
All generalisations are false, except this one.
____________________________________________________________________________
Sapere Aude - Dare To Be Wise
Wesley College Melbourne is a world class coeducational independent school
developing the whole person through timeless principles of learning:
- to know
- to do
- to live with
- to be
with innovation and wisdom
ABN 38 994 068 473 CRICOS 00354G
____________________________________________________________________________
This email is intended only for the use of the individual or entity named
above and may contain information that is confidential and privileged. If
you are not the intended recipient, you are hereby notified that any
dissemination, distribution or copying of this email is strictly prohibited.
If you have received this email in error, please email a reply to Wesley
College and destroy the original message.
_______________________________________________
http://www.edulists.com.au - FAQ, Subscribe, Unsubscribe IT Software
Development Mailing List kindly supported by http://www.vcaa.vic.edu.au -
Victorian Curriculum and Assessment Authority and
http://www.vcaa.vic.edu.au/vce/studies/infotech/softwaredevel3-4.html
http://www.vitta.org.au - VITTA Victorian Information Technology Teachers
Association Inc
------------------------------
Message: 3
Date: Thu, 10 Mar 2011 08:22:45 +1100
From: Mark KELLY <kel at mckinnonsc.vic.edu.au>
Subject: Re: [Year 12 SofDev] SD key knowledge
To: "Year 12 Software Development Teachers' Mailing List"
<sofdev at edulists.com.au>
Message-ID:
<AANLkTikdR+go8sX2vxnwusfFuGXsJ_9aoZWSqpVMm+nB at mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Hi Andrew. I just wanted to eliminate the very real possibility that I had
missed a blindingly obvious reason for the key knowledge being included.
>From your reply, it seems that you can't see its relevance either.
In that case, I'll escalate the enquiry and report back...
Cheers
Mark
On 9 March 2011 20:18, Andrew Shortell <shortell at get2me.net> wrote:
> Hi Mark
>
> [nice ppt btw]
>
> Each and EVERY member of the study design panel should be able to
> clearly and unequivocally, definitively answer your question because
> they put it in the study design. It did not get there by accident. All
> members of the panel are responsible for the document...
> Members of the panel discuss (and read) the document and have the
> opportunity to clarify anything that they do not understand.
> Just occasionally something gets missed ... That is why we have errata
> and corrections published (and I know all about those!)
>
> If it is not an errata the there must be a definitive answer so let?s
> just ask the panel to provide it rather than us guessing, perhaps not
> getting it in the way that the panel intended and absolutely missing
> what the exam setting panel might think. We do NOT want the exam
> setting panel to receive a torrent of unwarranted adverse comments.
>
> As mature sensible professionals we should all be working towards a
> common set of understandings that are generously shared (as per this
list).
>
>
> [btw ? at least a dead dog does not fight you when you stick the
> cotton bud in to its ears! Try doing an alive Alaskan malamute! ]
>
>
> Andrew
>
> --
> Andrew Shortell
>
> Heidelberg Teaching Unit
> Ph 9470 3403
> Fax 9470 3215
>
> c/o Reservoir High School
> 855 Plenty Rd
> Reservoir 3073
>
>
>
> On 9/03/11 1:21 PM, "Mark KELLY" <kel at mckinnonsc.vic.edu.au> wrote:
>
> *SD U3O1 KK04
> Purposes and functions of the physical layer (Layer 1) of the OSI and
> the relationship of the physical layer to the Transmission Control
> Protocol/Internet Protocol model
> *
> For quite some time now I've been avoiding this KK because I'd rather
> clean a dead dog's ears than spend time on the OSI.
>
> But in the end I had to find the cotton buds and get stuck in, and I
> think I have a reasonable overview of the OSI and how TCP/IP maps to
> it. (even produced a draft slideshow
<http://www.vceit.com/slideshows/SD-OSI.ppt> ).
>
>
> But the second part of KK04 really has me baffled: *the relationship
> of the physical layer to the Transmission Control Protocol/Internet
> Protocol model.
> *I know that TCP/IP's Network interface layer maps to OSI's physical
> layer (and the data link layer), but for the life of me I can't see
> how it's any more significant than any of OSI's or TCP/IP's other layers.
>
> Can someone suggest why the relationship between the OSI physical
> layer and TCP/IP is so significant?
> Has this relationship been in the papers? Has this physical
> relationship resulted in offspring?
> Is Mr OSI going to be on Oprah... or the Jerry Springer show?
>
>
> _______________________________________________
> http://www.edulists.com.au - FAQ, Subscribe, Unsubscribe IT Software
> Development Mailing List kindly supported by
> http://www.vcaa.vic.edu.au - Victorian Curriculum and Assessment
> Authority and
> http://www.vcaa.vic.edu.au/vce/studies/infotech/softwaredevel3-4.html
> http://www.vitta.org.au - VITTA Victorian Information Technology
> Teachers Association Inc
>
--
Mark Kelly
Manager of ICT, Reporting, IT Learning Area McKinnon Secondary College
McKinnon Rd McKinnon 3204, Victoria, Australia Direct line / Voicemail: +613
8520 9085, Fax +613 9578 9253 kel at mckinnonsc.vic.edu.au
VCE IT Lecture Notes: http://vceit.com
Moderator: IT Applications Edulist
All generalisations are false, except this one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.edulists.com.au/pipermail/sofdev/attachments/20110310/49aa3153/at
tachment-0001.html
------------------------------
Message: 4
Date: Thu, 10 Mar 2011 09:31:04 +1100
From: "Bell, Kenneth C" <bell.kenneth.c at edumail.vic.gov.au>
Subject: [Year 12 SofDev] UCD do have relevance ....
To: <sofdev at edulists.com.au>
Message-ID:
<2A725A8470E90F4C9FDEDF57A0E8D98A0258CA0F at edusm01.education.vic.gov.au>
Content-Type: text/plain; charset="us-ascii"
Hello,
Took my Physics students to Luna Park Physics Day last Thursday.
My I.T students are a subset of the Physics class so I arranged to drop in
at IBM Southbank and meet up with my nephew who is a Project Manager there.
Not much to see there but he gave a fantastic talk.
He gave a great talk to the students about what IBM does and in particular
what he does. He stressed that as a software engineer, he considers himself
to be like any other engineer in civil, mechanical, electrical, chemical,
environmental, ... He uses I.T. technology to solve problems.
He stressed the importance of establishing networks of people to help you
solve problems... which is what I think this edulist group does
exceptionally well.
I asked him about UML and in particular, Use Case Diagrams.... He said, it
was a standard practice that all IBM projects used. Students enjoyed hearing
this as it gave extra validation to why we are studying it.
Ken Bell
Mortlake College
Phone 03 5599 2204
Fax 03 5599 2503
Email: bell.kenneth.c at edumail.vic.gov.au
<mailto:bell.kenneth.c at edumail.vic.gov.au>
Important - This email and any attachments may be confidential. If received
in error, please contact us and delete all copies. Before opening or using
attachments check them for viruses and defects. Regardless of any loss,
damage or consequence, whether caused by the negligence of the sender or
not, resulting directly or indirectly from the use of any attached files our
liability is limited to resupplying any affected attachments. Any
representations or opinions expressed are those of the individual sender,
and not necessarily those of the Department of Education and Early Childhood
Development.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.edulists.com.au/pipermail/sofdev/attachments/20110310/7d64fe03/at
tachment.html
------------------------------
_______________________________________________
sofdev mailing list
sofdev at edulists.com.au
http://www.edulists.com.au/mailman/listinfo/sofdev
End of sofdev Digest, Vol 72, Issue 28
**************************************
_______________________________________________
http://www.edulists.com.au - FAQ, Subscribe, Unsubscribe IT Software
Development Mailing List kindly supported by http://www.vcaa.vic.edu.au -
Victorian Curriculum and Assessment Authority and
http://www.vcaa.vic.edu.au/vce/studies/infotech/softwaredevel3-4.html
http://www.vitta.org.au - VITTA Victorian Information Technology Teachers
Association Inc
More information about the sofdev
mailing list